that will work if you have a unix server with a simple config, totally managed trough systemv scripts.

but, in reality, you have server with multiple services, servers containing multiple virtual servers.
some services need to be properly shutdown with some command, and some even need some time since you issue the stop command before you could actually bring down the Os itself.
that is why i pointed that instead of the shutdown command, use a script.
it should be named the same way, in the same path on all servers to allow a simple while in the "master" server.

and each script will be responsible for all the logic for the stop procedure of this weird services that cant simple be killed. the sleeps to ensure they have some time to end correctly, ect

i remember one place i used to work, they used a protocol over tcp/ip to transfer messages between servers.
you had one gateway, receiving msg, distributing them to the proper apps and databases, and replying to them.
this gateway was also listening to other gateways in other countries from the same company.
the thing is that you couldnt simple kill everything down.
you had to isse stop commands to all the backends, to stop answering requests, but dont kill the current ones, after some time (something like 10 mins)
in the meant time, you had to tell the gateway there was problems, so it had time to tell others gateways, so they could start answering the request sent to him.
after all the backends where stoped, , you had to stop the gateway.

and that is a simple example. i have seen way more complicated companies, where they had multiple machines working in line.
they neede a complete hour to shutdown the hole procesing line, without lossing data in between