To clarify, the lack of ms-appinstaller:// protocol doesn't stop you using AppInstaller in the wild. It means the user has to download and open the .appinstaller file as if it were an installer EXE. The UX is actually more similar this way to how Windows users expect installers to work.
The downsides of losing ms-appinstaller:// are:
- You can't pass initial flags to the app this way, which in turn worsens the UX because you can't (easily) auto-sign in users to an online service.
- The user ends up with a .appinstaller file lying around that they then have to delete. Same issue with installer EXEs of course.
- You lose some advanced MSIX features related to dependency handling and bundles for some reason.
- You lose OAuth integration.
It's indeed bizarre and distressing that this feature is now enterprise only with no plans to bring it back. In particular because it implies that they think the protocol handler is insecure (why? there's no reason why it should be so given it's just about saving one or two clicks), but that the security issue goes away if an admin has to manually enable it (based on what information/assessment?).