The call to Application.ProcessMessages is most likely just needed to allow the MSHTML activeX control time to finish loading the document. It sounds like they're using cooperative multitasking here to simulate loading the doc in the background - the ActiveX posts messages to itself to process the next chunk or whatever.
Normally, this wouldn't affect your app's flow because the doc load would happen as part of your normal message loop. But because you're wanting to load the doc synchronously (not do anything else until the doc is fully loaded), you're sensitive to the way it's doing background loading via messages.
One solution: see if you can remove the requirement to load the doc synchronously. Let the load happen when it happens, but move the check for readState = complete into a timer, perhaps on a 1 second interval. When the timer discovers the doc load is complete, then fire off your downstream food chain activities.
Another solution: Display a modal dialog while waiting for the doc to load. This has the benefit of disabling the rest of your UI so you don't run the risk of reentrancy. Calling ProcessMessages means the user can still interact with your window, click on buttons, menus etc. Usually this will lead to problems. Displaying a modal dialog ("progress dialog?") avoids reentrancy by disabling everything behind the modal dialog.
Third possibility: Replace Application.ProcessMessages with PeekMessage and logic to examine the message to decide whether to let it go through or put it back on the message queue for later. This is a bit dirty but might work in very special cases.
I recommend approach #2, the modal dialog.