If there is no longer any process running that would handle a login attempt (i.e.
getty on the console or serial port, or
sshd or similar for network connections), then there is very little you can do.
If there is a chance that the
init would still be providing a
getty process for the console, but the current holder of the console has hung for some reason, you might try Alt-SysRq-k to kill the hung process and hope that
init will start a new one for you. But if you've ended up in that state at the tail end of a shutdown, it might not help, as
init has already stopped the
gettys and not starting any new ones.
The talk of rebooting being a "death sin" is a bit of hyperbole aimed to head off bad habits that some new Linux users may have inherited from their previous operating systems. There is a time and place for everything, including a hard reboot. If you're reasonably sure that there are no other options, then so be it: a large uptime is usually not a goal per se, but a side effect of tight SLAs. And if you have a tight SLA, you want to quickly investigate what has gone wrong, and then do whatever it takes to get the system back up and running ASAP. Once that's done, you can dig into logs and crash dumps to try and find out the root cause and if possible, prevent it from happening again.
I'we worked as enterprise Linux/Unix sysadmin for almost 20 years now. During that time, I've seen quite a few systems so hopelessly wedged that the only solution was to reboot them. Sometimes the reason was broken hardware; other times, an application with a memory leak, or an application acting like a fork bomb when a database connection was not available (a tiny bug in error handling code :-/ ).