I believe it is because it includes a suite of enterprise management features in addition to Gmail-related features. (Search for "google basic mobile device management" for more info.)
There are certainly valid, conflicting opinions around signing/notarization requirements for software. But notarization does provide end users with some safety guarantees that legitimately make running the software less risky. The scariness of "are you sure you want to run this" prompts is fairly grounded in real risk assumed by the end user.
There are a couple of legitimate reasons, namely the expense/KYC process of an Apple Developer Program membership and/or the complexity of integrating signing + notarization into existing build pipelines (but XCode does makes it pretty straightforward to cut an ad-hoc release that is signed and notarized).
In my opinion at least, the most likely reason is that Apple is refusing to notarize the software. If this is the case, people really should not be running it.
In your example, replacing bulky self-checkout machines (analogous to removing road/surface parking real estate) offers a significant benefit to everyone. More room for what everyone actually wants most: books. The preference for self-checkout machines forces a cost on everyone for the benefit of a few.
I don’t think this analogy is quite correct. Driving on a particular route is not a driver’s objective like reading a particular book is a reader’s objective. The driver’s objective is arriving at a destination. The objective in driving is not a finite resource, but the multiple route options to the objective can be, which differs substantially from a library queue.
1p has some native support for hardware keys (https://support.1password.com/security-key/), but you can always use Yubico Authenticator for any applications that force you to use TOTP.
Wow, very surprised to see no DMARC records in place for harvard.edu or their various subdomains. It may be possible that a single DNS record could have prevented this whole madness.