I often find it helpful to hide the access shell so that the user must use my 'Exit Database' button, this provides a certain appealing readability to the code that I then want to run whenever the database is closed, due to being behind the btnExitDatabase click event rather than mysteriously in a form's Unload or Close event....And has the added benefit of not firing when you're in dev mode and go from Form to Design view, which can complicate things exponentially and require jumping through more hoops to avoid, like implementing a Dev and Prod mode.
Why want to know? It can be helpful to know who is currently in the database (for broadcast messages, general communication, or announcing emergency downtime), analyzing app utilization, etc. There also might be any number of things you'd want to do when the user exits - like unlinking tables that were linked on the fly, un-mapping a drive that was mapped on the fly, the list goes on, updating tables or combos etc.
Personally, I have never had situations where users Kill the database (Task Manager, etc) as long as I give them an Exit Database button that always works, unless they experienced some major problem with the database.
Even then, it is possible to record when the database was closed by getting a little more creative:
1) when the db is opened, Create and Execute a vbscript that loops indefinitely, attempting in vain to delete the access Locking file
2) when the script is finally able to delete the Locking file, that means the database is no longer actually open - even if Killed by user
3) at this point you can execute (ADO, DAO, automating Access.exe, etc) anything needed to accurately reflect who is or isn't in the db or anything else needed.
One of my uses of VBScript has fallen in this category - having to do things outside Access for whatever reason - especially "just before" it's opened, or "just after" it's closed.