However, I cannot find anything that justifies that statement?
You seem to have a method available for "how" to do this. You want to know WHY you would do this. OK, I'll give it a shot. You need to shut down to protect your database from the following scenario.
User X logs in. Diddles with the database somehow or another. Has a form open and has a partial change pending. So the database has a lock file on the BE showing that user X is making a change. User X is looking up something he needs to finish the transaction.
But suddenly user X takes a phone call and has to leave the office for some obscure reason. Maybe Hell just froze over and he has the only key to the boiler. So the site protocols force the computer to become screen-locked by Windows after some amount of time. That means the change is still there but not visible behind the screen saver. Access is in the "waiting for input" state.
So user X doesn't get back before close of business. And that night is the night that Microsoft, in all of its wisdom, publishes new patches with a mandatory download and reboot. So that buffer that was locked REMAINS locked. Windows reboots, but because Access didn't follow through on releasing the lock, the BE file (on a machine that might not have rebooted yet) is now locked as well because the channel to the FE system was closed in a ragged way. And that means that the file system on the BE machine is now "waiting for Godot" and as we all know, he ain't coming.
Now, until you reboot the BE's host, that BE file is locked hard. And there is not one bloody thing you can do easily to fix it short of a reboot to reset all network sockets.
If you had a timer running on the form in question, you would have had the OnTimer routine do a form Undo followed by a form Close followed by an Application Quit. At some point or another, the file system lock on the BE file would be released and nobody would give a rat's patootie about whether user X's machine got rebooted or not.
Now, there is one other reason you might wish to do this. If your network is at all shaky, a long session has a greater probability of running into a "shake" than a short session. Therefore, you would wish to reduce the "window of exposure" to network hiccups for untended machines. And that is where an auto-logout would be helpful.