The reason for this is that the browser and the actual TOR client is different softwares. Technically, the browser connects to a SOCKS5 proxy on 127.0.0.1 and then asks it to resolve a .onion domain. If a browser would to treat *.onion as a secure context as itself, a rogue party could hijack the connection of a NON-TOR user, and then ask the browser to redirect to a *.onion URL, which then is, by the attacker, resolved to his server, and he would then gain access to all "secure" tools over a unencrypted connection.
In some cases, the web browser and TOR client won't even run on the same physical hardware, since some users use a "central TOR router" (looks like a normal home router but with custom firmware to handle TOR) to handle their TOR traffic from their whole home network without having to maintain a circuit for every client in their home network.
One thing the TOR software could do, is to add its own .onion CA into the system - and actually GENERATE a keypair (so every .onion system would have different CA private keys) and then mint certificates on-the-fly. For those using TOR in central routers, the name-constrained certificate could be on a downloadable CA link, which was generated during setup of the central TOR server inside home NAT router.