Ah yes, I too remember when COMODO was ripped out of browsers in 2011 when it came to light they gave sign-anything rights to a bunch of resellers, one of whom was hacked. And then again in 2016.
And another fun one unrelated to signing was when they tried to trademark "Let's Encrypt" in 2015.
But yes, it is not a common issue and effort would be better focused on improving site security in other ways. (unlike the rest of my comment, this line isn't sarcasm.)
I feel this every day I talk with cloud-brained coworkers.
I manage an infrastructure with tens of thousands of VMs and everyone is obsessed with auto scaling and clustering and every other thing the vendor sales dept shoved down their throats while simultaneously failing to realize that they could spend <5% of what we currently do and just use the datacenter cages we _already have_ and a big fat rack of 2S 9754 1U servers.
The kicker? These VMs are never more than 8 cores a piece, and applications never scale to more than 3 or 4 in a set. With sub 40% CPU utilization each. Most arguments against cloud abuse like this get ignored because VPs see Microsoft (Azure in this case) as some holy grail for everything and I frankly don't have it in me to keep fighting application dev teams that don't know anything about server admin.
And that's without getting into absolutely asinine price/perf SaaS offerings like Cosmos DB.
Having the tool actively prevent classes of errors is a worthwhile endeavor, but I do agree it gets overly focused on alone when several other _massive_ classes of vulnerabilities continue to be introduced. At a high level though, it is a lot easier to just have a framework enforce 'x' on all devs to raise the minimum bar. It doesn't help that the average Rust-bro, from which a lot of these memory safety arguments come from, is utterly terrible at making that case in reality. Case example: https://github.com/pyca/cryptography/issues/5771.
I think a lot of the arguments around C++ for example being 'memory unsafe' is a bit ridiculous because its trivial to write memory safe C++. Just run -Wall and enforce the use of smart pointers, there are nearly zero instances in the modern day where you should be dealing with raw pointers or performing offsets that lead to these bugs directly. The few exceptions are hopefully with devs that are intelligent enough to do so safely with modern language features.
Unfortunately, this rarely gets focused on by security teams it seems since they are instead chasing the newest shiny language like you mention.
The only way this stuff trickles down to the masses is people that know what they are doing forcing it on them through their products. Very, very few 'engineers' actually go out and learn the state of the art these days in my experience, with most just culting around whatever the current marketing fad is.
Hell just look at SDWAN land and everyone acting like it is the second coming of jesus when it is just a fancy marketed version of technologies that have been available for decades.
I personally push for IPv6-only internal networks whenever possible, and have deployed several such designs in datacenters.
Unfortunately, a lot of applications are building on platforms where IPv6 is an afterthought if even present at all. Take for example Azure, where IPv6 support is a fucking joke. From core services like Route Server not supporting it, to it being impossible to build v6-only networks due to forced v4 subnet and vNIC requirements, to many services that Microsoft provides only running on v4.
As much as I want to push IPv6 everywhere, that physically cannot happen until companies support it for all use cases. In the mean time dual stacking can be better than nothing but the complexity is non-trivial when the alternative is just running straight v4...
IME when people start using self signed certificates they trust anything that is presented, with no pinning. That means that so long as you MITM it with something with it's own self signed cert it will work just fine.
And another fun one unrelated to signing was when they tried to trademark "Let's Encrypt" in 2015.
But yes, it is not a common issue and effort would be better focused on improving site security in other ways. (unlike the rest of my comment, this line isn't sarcasm.)