Ok, I was able to confirm what Warren found out. 

If you are running in an AppPool configured with a unique identity and the site is set to use impersonation then the identity during application_start is the configured identity of the AppPool.

Everything is happening normally until the EventQueue controller attempts to delete the Message after it has been processed.

This is when the windows login prompt appears because that user does not have permission to delete.  Hitting refresh clears the error because the application is now past the startup event and no further attempt is made to delete the message.  When the application is restarted the error will come back because the EventController is attempting to delete the message again after reprocessing it, which is not good. 

A workaround for now is to delete the message manually after the error appears so that further application re-starts will not attempt to re-process the messages that have allready been processed.

Another option is to give the configured app pool identity special permission of only "delete" for the EventQueue folder.

I'll work out a fix that doesn't require a delete during application_start for the next release.

Actually we've never run into the issue because we assign a unique, dedicated application pool to each asp.net hosting account.  While this is more resource-intensive, it also really is the best way to do it.  It creates even more of a sandbox for each app.

So, it seems the larger question is to what extent should DNN compromise to allow it to run on any shared hosting environment?  That's been a long-standing issue.  Nonetheless, I do agree with you that if Microsoft made that change, this wouldn't be an issue in either environment:  neither high-end or dedicated hosting, nor commodity hosting.