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.
ITts a lot better. I've ported libdbus-1 code to sd-bus and in practise I saw 100s of lines are replaced by about 20, with better error reporting on top of it.
Which, for example, is why you can't use `>` in `[` based expressions. Bash thinks you want to redirect the output of `[` to somewhere else. This restriction is lifted for `[[` and makes for much more natural looking code.
Ironically, if the given example was written in pure bash, it would be violating best practices. You don't parse ls line-by-line because you can't make the assumption that filenames will map to lines.
Taking this contrived example at face value, imho, I'd instead place the "best of bash" for the particular task with file globbing.