If the same CentralAuthUser object is loaded multiple times in the same process, each load triggers a WAN cache read. Fixing that should be trivial and low-risk - just make sure the in-process cache is memory-limited (e.g. HashBagOStuff with an entry count limit) and is invalidated any time the WAN cache is.
Filed mainly because SessionManager used to initialize the session multiple times for a single request, due to backwards-compatibility with PHP's internal session handling and limitations on what can be cached in-process without messing up HHVM garbage collection; I cannot reproduce that behavior anymore though. @Anomie, did something change there?
While SessionManager does create a Session object multiple times, it will generally only be determining the session from the request cookies and headers once. The rest of the times it should just be loading the session from the SessionID saved in the WebRequest after that first determination.
The PHP backwards-compatibility stuff (MediaWiki\Session\PHPSessionHandler) never actually determines the session from the request cookies and headers, since it always deals with a passed-in session ID.
However, CentralAuthSessionProvider::refreshSessionInfo() probably will be called for every Session object created, even if it is created from an ID, and that does create a new CentralAuthUser for each call.
Unfortunately we can't use a CachedBagOStuff here, since CentralAuthUser stores its stuff in a WANObjectCache rather than a BagOStuff of any sort.