Because xxx.onion is essentially hostname. One can conceivably have https://example.onion, ftp://example.onion, telnet://example.onion, and so on.

The reason it has to be done at the DNS level, rather than at the URI scheme level, is because any protocol can be routed over TOR.

Well, there's nothing keeping a well-defined tor scheme from including the protocol information in it, is there? For example, I could imagine specifying a tor URI in my git config: onion:ssh:pcl@aoeusnth or onion:http:aoeusnth

The point is its still http.

Think of TOR as acting like a VPN or point-to-point tunnel. You can conceptually think of it as another network interface plugged into your network. The policy you choose what to route over it is your own. It doesn't affect how any other protocols function.

I can still access regular sites over TOR. I can also access regular websites over a VPN. openvpn+http:// isn't exactly useful either for the same reason.

And there are other special tld. Your multicast domain group (e.g. .local) is also special. Your dns resolver sees the TLD and resolves it specially. But once again, doing multicast DNS doesn't impact http, git, ssh, etc. So it be silly to have to write mdns+http://... as well.

And if you where to join them, then you have to describe what kind of behaviour should happen if, for example, on openvpn+http://foobar.tld you hit a hyperlink to http://baz.tld. Do I rewrite this to prepend openvpn+? Fail? etc.

Because you then would have to patch all your software to understand the scheme. Which might actually be a good idea from a security POV, but is harder.

I think the simple answer is that they started doing it a certain way and then didn't want to change it.