In short, you're right
Most users just want to navigate one obvious step at a time. If you give them a menu that feels like it needs to be "closed," then they don't want to have any unnecessary actions bundled into their obvious prompt: "close". I think most would agree that your intuition is correct - allowing navigation simultaneous to closing a pop-up menu isn't expected or welcome, is rarely necessary, and poses unnecessary risk.
In long... it depends!
You can design totally awesome environments that restrict actions to one-at-a-time, and comparably awesome environments that allow multiple actions from a single input. But, the interface needs to be obvious and intuitive whether you've brought users to a "bundled action" or "singular action" space.
My understanding of the underlying construct that dictates how users expect their powers of navigation to work: Accepting clicks from objects ought to occur only in states where the antecedent behaviors of informed clicking are enabled and encouraged - that is, browsing. Zones of discouraged browsing (e.g. a grey dialog box, a minimized window, a not-current tab in your web browser) aren't actionable, almost ever. If browsing outside of a specific area is noticeably hindered (by significantly desaturating the page and obscuring it with a big ol' modal box on top), then users won't expect to be able to act on those un-browsable elements.
We don't form intentions and plans to interact with hard-to-see objects, especially when there are unobstructed, popped-up elements to deal with. When we create a clear hierarchy of "emphasized objects" and "de-emphasized objects," users expect (and plan!) their actions to apply to the forefront elements at least primarily, if not exclusively.
A good analogy here is navigating a DVD menu. Quite often, the first few moments of playing a DVD are "locked" from user input, because the UI really wants you to watch legal boilerplate, trailers, ads, introductory animations and the like. While these events unfold, there's an interactive menu obscured, waiting for user input. We will eventually work with that menu to watch some content, but we won't form a clear concept of action until we are actually looking at the menu. It might be easy to guess where the buttons will be, and what they'll do, but it can't be planned for, navigated, or acted upon until it's sitting in front of us.
Imagine breaking this convention. For some budget or bootleg DVD UI, user input is accepted even while playing the "locked" welcome reel. Once the menu emerges, all the buttons you might've been un/intentionally pressing for whatever reason (to skip past the trailers, to preemptively Play the disc, to wipe off some pizza residue from your remote), all the actions that didn't have meaning yet, suddenly were acted upon by the system -- Mayhem!
It's a silly and overbearing analogy, but it makes the underlying UX philosophy clear - we expect to have power to interact with only that which we can see. If something is obscured or hidden, we don't form plans about it, and any actions we take shouldn't warrant response from hidden elements.
Doing "click + navigate" well
This points to the other side of the coin - if you do want to enable actions on elements outside of popped up boxes and menus, then make it clear that users are welcome to form that plan of action. Don't obscure or significantly change elements that still avail themselves to input. Let your users form plans about interactive stuff, and keep them from forming plans about non-interactive stuff.
A great example of this is on the responsive http://stackexchange.com/sites menu. When an object is clicked, the neighboring panels shuffle to make room for the expanded divs. Nothing else changes about the appearance of the page to suggest it is discouraging browsing behavior. Nothing pops up to obscure and de-emphasize anything else. It's clear that actions are multiply powerful, and allows clicks that just "exit" as well as clicks that connote "exit+navigate". The rest of the page remain as browsable as ever, with the elements hover-responsive and clickable as before.
