UserArrayFromResult lets extensions do their own caching when a batch user lookup happens, but there are two problems with it:

• It is too specific, bound to the mechanism of passing a query result to User::newFromResult(), but that's going to be abandoned eventually, in part because we are replacing most uses of User with UserIdentity, and in part because we use query builders that return objects (such as UserSelectQueryBuilder) rather than passing query results to non-RDBMS-related classes.
• It lets handlers modify or replace the resulting UserArray, which is fragile. The only actual implementation in CentralAuth replaces the UserArray with a CentralAuthUserArrayFromResult subclass, but the parent class is not marked as safe for subclassing so it's entirely unclear what actions are safe in the subclass. (This led to T387148: MediaWiki core selenium test "Special:RecentChanges shows page creation" fails consistently when CentralAuth loaded in CI recently.)

We should probably replace it with a new hook (WarmUserCache?) that's called every time a batch user lookup happens (so both from User::newFromResult() and UserSelectQueryBuilder), and sets the expectation that handlers should implement their own caching (so e.g. CentralAuth should have a CentralAuthUserFactory or CentralAuthUserLookup, and that should have an internal cache which is warmed when the hook is called).

The CentralAuth part could be done separately as a first step - keep using the UserArrayFromResult hook, but discard the CentralAuthUserArrayFromResult and just warm some cache when the hook is called.