Hi John,
You are following me perfectly 
Even though the UEM agent opens its config files for read, from a read-only share, the file server grants a write caching lease. Only a single client can have such a lease, so if another client subsequently wants to read that same file, the file server tells the first client that it needs to let go of its write caching lease. Once the first client has acknowledged that request, the file server responds to the second client. (Which then gets the write caching lease, so if a third client wants to read that file, all of this happens all over again, ad infinitum.)
Write caching leases for read-only files are a bit weird, but not necessarily a problem. Having that additional traffic for "let go of your write caching lease" is not ideal, but also not a problem in and of itself.
However... If the file server can't reach the client that it granted a write caching lease to, it will try a few times, and eventually time out. Only once it times out will it respond to the second client that wants to read this file – that's the delay we're seeing.
With non-persistent VDI, VMs release their IP address at some point during the shutdown (before being deleted), which means that the SMB client might not be able to inform the SMB server that it's going away. Which subsequently means that the server will try to contact a client that's no longer around, resulting in the delay as described above.
For instance:
- User logs of from VM1
- UEM path-based export is performed
- UEM agent reads config file
- SMB client gets write cache lease
- Export is completed
- VM gets deleted
- User logs on to VM2
- UEM path-based import is performed
- UEM agent tries to read a config file
- File server tries to contact SMB client on VM1 to have it give up its write cache lease, but can't, as it's no longer around.
Delay occurs.
Note that the delay can occur just as well if there are two logoffs occurring shortly after each other. I guess the focus is on delays during logon as those as much more noticeable for users.
Explicitly stopping the Workstation service effectively informs the SMB server that this client no longer needs its leases (and in our tests, this runs before the VM releases its IP address, so this information actually makes it over to the file server), preventing the server from subsequently trying to reach a client that no longer exists.
EDITED: Clarified that the problem most probably relates to the fact that an Instant Clone VM releases its IP address during shutdown, which might affect the "normal" shutdown of the Workstation service, in the sense that by then it might have lost its network connectivity. (Where "Clarified" means: I did not know this when I wrote my initial description 