I don't know anyone who would advocate using the raw git: protocol without ssh. Setting up an ssh key is not a conspiracy to make it more difficult. Using ssh is simply how it's done.
I'm not a fan of the github app or github cli, I prefer the standard tools. However, calling this "embrace, extend, extinguish" is weird.
But it does require having an account or public key on the server. https does not require having an account, but the http transport protocol is less efficient compared to the native git protocol. If git supported a protocol like gits where it could establish a TLS connection to the server and then use the git protocol for fetch or push, that would be ideal.
It's a bit of a hassle, but I suppose you could always create a public read-only account with a 'private' ssh key made available in the readme.
I work a lot of public repos. I want anonymous reads and clones to be super easy on my users.
I don’t like forcing people to log in just to read. I don’t care about encryption as the integrity of anonymous clones isn’t something I suspect will be abused.
There’s a large set of “I don’t care” style projects where I’m just looking to grab a copy. So even if my ISP (or some nefarious jerk on the same WiFi) could MITM, I don’t care. Plus, I’m not aware of any attacks like this because of the whole git checksum thing it’s harder than injecting into http traffic.
For stuff I care about, I log in.
(it could also reduce encryption and decryption load at both endpoints, and if you have other means to enforce content integrity then the channel itself does not have to been encrypted)