If privacy is not a concern (eg. you specifically want global visibility of all aliases) and your lookups are far more frequent than write operations (add, delete, change aliases), then some of the concerns of MapOnLedger are not as grave - so it might be the better option then.
The LedgerAsMap option is better for when the disclosure of an alias is considered a business process, and each party has a set of aliases it interacts with that is much smaller than the global population. In this case a call to the ledger to query all known aliases is acceptable eg to populate a dropdown.
So I think it’s really a tradeoff and the ideal solution depends very much on the use case.
There are also mixed form, for example each party could also (besides the individual alias contracts it knows) maintain a directory contract for them to allow more efficient reads. You’d have to ensure that this is updated during the disclosure mechanism.
Regarding the observer everyone I think we all have wished at some point for the existence of that, and the related feature of “blinded observers” that don’t know about each other. Maybe @bernhard can comment if anything there is on the horizon as part of the read model overhaul.