As others already pointed out, this depends deeply on your answer to complex philosophical question what is "Linux" :).
Yes in this case, as in many others, the "GNU/Linux" meme suddenly becomes very important and relevant.
So now let us first look at actual "kernel truth", that is, how the mechanism works for real.
As far as normal kernel is concerned, as long as PID1 is running, everything is fine and dandy. But should PID1 crash, no matter how hardware/software healthy the machine is, this will cause immediate kernel panic, which is equivalent to killing all processes with SIGKILL or has roughly same effect as immediate power loss.
If I remember correctly, most stock Linuces will end up stuck here by default, with PANIC message printed on console waiting with halted CPUs until operator comes and hard resets/shutdowns the machine physically (or virtually, if VM). Some BDS will by default wait 15 seconds in this state and then reboot themselves.
So this is one part of the thing.
The other part is special Linux kernel syscall called reboot(). This syscall is accessible only to root user processes, and allows you to control kernel behaviour: it can kexec from current kernel into next kernel in chain, reboot/reset the machine physically, poweroff the machine physically, halt the machine physically and finally suspend (hibernate) the machine.
Besides hibernate (I am not sure about that one) any of the actions mentioned above is equivalent to kernel panic action in the first case (i.e. all running processes are killed immediately as if by powerloss), the only difference is that kexec will immediately handover control to next kernel in chain, while reboot, poweroff and halt will either reboot all the cpus, shutdown power to the whole computer or halt all cpus in it, without causing a panic :).
Halt state is basically all-software-is-off state, equivalent to how you used to turn off old computers ("You can now safely shutdown the computer") before motherboards grew circuits to power off themselves off autonomously.
The important part to realize is that PID1/init must be running when reboot() is initiated.
Now you understand that these two controls are really quite bare bone. You also now understand, that everything that happens in-between some user command to shutdown and reboot() syscall is completely distribution dependent.
How this sequence is handled usually depends on init package the distribution is using. On majority of modern distributions this is handled by systemd, it's PID1 receives control commands from
shutdown commands (these should be really named
systemd-shutdown, because they don't work with other inits) and do respective actions.
You can dig somewhere on systemd author's site how shutdown protocol is implemented there, as I remember reading that (take it with grain of salt as, systemd is everchanging and most of deep information about it is from timeframe circa 2012~15 and really outdated).
Now we are getting into more exotic realms.
@rhellen gave you somewhat simplified explanantion of crappy sysv init poweroff dance.
runit based distributions have completely different mechanism, and so do
s6 based systems.
So the real answer is it depends on your distribution a lot.
On some ancient sysv based Linux systems for example
poweroff commands are equivalent to their raw syscall counterparts (and I think on BSDs too), so neophyte admin, at least a typical systemd user, has great ability to kill the whole box "the power outage way" :). Similar to
killall story on Solaris.
shutdown always works the same way on almost all platforms, so when in doubt, always use that one.
rebootcommand. Or log out of your current session and start a new shell/console expressly for the purpose of issuing he