Interesting - is the idea then that during background an app's frames are not being displayed, but it should keep its render loop going? Or the idea that during background the app is throttled to 5 fps, counting on reprojection to keep the view reasonable? Do we have a belief that UAs can throttle enough to eliminate the privacy risk without causing users to be uncomfortable?

Or sometimes background is during a sensitive overlay (e.g. 5 fps) and sometimes background is during a non-sensitive overlay (e.g. 60/90 fps)?

Yes. This is to allow for UAs to have some flexibility in how they display sensitive content AND to let UAs take advantage of some platforms features where the content is still visible even when the input focus is elsewhere. Primary example of that I can think of is Steam VR, which continues to display the app (lower res and greyed out, but still live) when you pull up the Steam overlay.
This is a situation in which the app would be put in that state but still pump frames at ~full speed.

You could also picture a scenario where the app is placed in that state but rendering is severely throttled to the point where it may only render intermittently to patch up around reprojection or even just process one frame to make a cubemap. This could be either for privacy reasons OR simply because the device lacks the horsepower to render two realtime stereo scenes at once. I don't believe the API should differentiate between those scenarios to the developer. Whether or not the UA is comfortable with that being sufficient to preserve privacy is up to them, though the hidden state is always available as a last resort.