In all cases where the app object in question is managed by an external task, Excel and Outlook and Word being prime candidates in this list, setting the object variable to nothing breaks the link between Access and the other task but doesn't terminate the task. It leaves that task in a "hanging" state because it is not under control of a keyboard - it is under control of a now-dead internal link. The task "remembers" how it was opened and its input channels reflect the connection, which was probably via SMB protocol.
It is correct that if you create a local object variable in a subroutine (including event routines) that the "End Sub" or "Exit Sub" will clean up all local variables. However, one thing that some folks do (including me) is put object variables in the declaration area of a general module that contains a whole bunch of support code for that specific type of object. If you do that, though, exiting a particular support routine won't kill the object variable because it isn't local. This is why you should always clean up what you messed with. And if it has a life of its own (but you don't want it to) then again, remember to clean up the messes you make outside of Access.
Not only that, but we had a discussion with a member of the Access developer team once. The thread should still be around but I can never find it. In passing he commented that there are times due to optimizations in SMB v2 and v3 protocols that even cleaning up a recordset by formally closing it is a good idea even if the recordset object was locally declared. Something to do with attempting to hold back the automatic writeback behavior of a recordset because of the higher network traffic implied for network-accessible back ends and the formal rs.Close operation forces the writebacks despite the protocol change. The person offering that post linked to an external article on the SMB v2/v3 changes. With Win10, SMB v1 is no longer the default protocol for Access connections so it becomes important.
Therefore, it is a good idea that for objects, you should close before you set the object to nothing OR before you leave scope. And it would be OK if you leave scope without first setting objects to nothing if you have at least closed or terminated them.