One of the arguments in favour of abusing the Web PKI to do other things is that tooling for the Web PKI is in a relatively good place. And a lot of other things that you might ideally hope exist actually DO exist for the Web PKI. There's independent oversight, somebody is actually reading those yawn-making audit reports, it isn't perfect but it's not just make believe either.
But on the other hand, the Web PKI is ours, and so if it suits us to change it we don't really care that this is annoying for your payment card systems, jet aeroplanes, nuclear submarines or whatever else you've duct-taped the Web PKI into. This was fun to watch with SHA-1 for example and is currently causing some fallout for names with underscores in (DNS can handle a name with an underscore in it but they're prohibited for hostnames. Lots of people ignored that, but that's their problem, not ours and they are not happy about that).
[0] https://www.ericsson.com/en/about-us/enterprise-security/pki
[1] http://crl.ericsson.net/Ericsson_Software_Deliverable_Integr...
[2] https://crt.sh/?q=%.ericsson.net
[3] https://en.wikipedia.org/wiki/System_Architecture_Evolution
[1] https://en.wikipedia.org/wiki/GPRS_Tunnelling_Protocol
[2] https://cyber-defense.sans.org/resources/papers/gsec/securin...
Can't seem to find anything on web.
On underscores: https://www.digicert.com/blog/digicert-pushes-underscore-ext...
On SHA-1: https://blog.mozilla.org/security/2015/10/20/continuing-to-p...
Part of the reason to do this is that if CAs issue the certificates then their customers buy them, and create pressure to accept them. If none of the CAs are willing to issue this never comes up.
Another is "unknown unknowns". Security systems don't play well with undefined behaviour, if we explicitly forbid everything we don't want to exist that minimises the risk of such undefined behaviour anywhere in the certificate handling code getting exploited. It's a defence in depth.