That's not what protocols are for, though. It would still be served over http, so what you're looking to replace is actually the world wide web, or www. In other words, http://app.microsoft.com is what you meant.
That doesn't have to be true. An app protocol could have, for one example, a structured always open connection and a new set of useful verbs/actions that are more conducive to apps. It could tell the browser to use a different rendering path with a different more comprehensive base UI set for another example.
These are already possible by retrofitting existing technology but the question being asked is what would a reimagined, more app friendly web platform look like.
Though in practice, subdomains are rarely used in that sense anymore (both www. and ftp. are declining in usage), while the protocol is used to determine the program that should handle the request.
Maybe https+app://microsoft.com is better? (plus signs are valid in uri schemes)
I am not so sure that all protocol schemes require that the transfer be over http. How about if I type ftp://example.com in the browser? Or https? Or gopher? :)
What should app:// support that http:// doesn't? Or, from another direction, what should http:// have restricted that it currently allows that we can allow app:// to handle instead? (and let's ignore the impossibility of carrying that out, since the discussion might be informative anyway)
The question you have to answer if you want a web-like thing is "how do we solve the problems of the current web for devices like phones, tablets, and TVs?" Then you have something that can potentially stem the move of eyeballs from an open and linkable web back to a bunch of clustered-off apps.
In other words, I think the question to be answered first is the fundamental browsing UX challenge for non-desktop devices, where you don't have mouse/keyboard all the time and browser apps are less always-open.
The author is mostly focused on security, but that alone won't move big groups of users. Much of what he describes reads to me as copying the current UX state of phone apps, not leapfrogging them.
We just use this protocol/schema to make sure that development URL links are tappable on your phone. Checking a URL domain works for lots of deep links, but not when you have IP addresses or dynamically generated ngrok URLs (like when loading an app from XDE).
You might ask, why do this when you can just scan or screenshot the QR code? Fun bit of tech debt: the current QR-scanning system was added to support the offline-only create-react-native-app setup, and the "send a link by SMS" flow predates that. If you've received an SMS with your development URL, it's pretty useful to have it tappable.
Related, this detail of the XDE <-> client app connection isn't really what people use for production, it's just for development and sharing with coworkers in most cases. To ship a "production" Expo app, users typically build an IPA or APK for uploading to the App Store and/or Play Store, where this URL is hidden from them.
http:// is for hypertext, app:// is for apps
app://microsoft.com/word should be explicit enough