Asking your ISP to cripple your connection like that is a horrible "solution", and usually isn't a change they're prepared to make by request. If you have the option of shopping around for ISPs, the one that doesn't do CG-NAT is usually the best choice.
I disagree with you. The majority of users don't care about being behind a CG-NAT (what you call "crippling"), and CG-NAT offers a very big layer of protection that avoids problems like the one on this article.
NAT adds latency to a number of applications (VoIP, video conferencing, gaming). Not so much in the translate IP/ports and keep some state, but in connection establishment. CG-NAT only makes this worse (not to mention it's becoming impossible to troubleshoot when issues arise).
Users don't explicitely care because they don't know. It doesn't make much difference when viewing YouTube videos, but there's more to the Internet than cat videos.
NAT is not a security layer. It's possible through techniques like STUN and such to discover and reach hosts behind a NAT.
CG-NAT is crippling because I want to receive incoming connections like anyone else who has a connection to the Internet should be able to. Router manufacturers can do better. The world does not have to consist solely of cloud-based middle-men who take full advantage of the fact that all your data has to pass through them, and that you have to trust them.
What's somewhat ironic to this discussion is that some Linksys routers modify STUN responses, which breaks legitimate functionality if the router is used with dual-NAT or CG-NAT:
This is very unlikely. Any ISP with some experience will make sure customers are not able to interact any more than they could from outside the network. That's network 101.
Having worked for large ISP's for around a decade, cheap comes first, customer safety comes last.
Also, QUIT BREAKING THE INTERNET. CGNAT is complete crap that breaks the internet peer model. Even ISPs not using CGNAT are pushing complete crap on users. For example last week I had a user that VOIP stopped working. They received a new integrated cable modem router from their ISP. If you rebooted the unit VOIP worked about an hour, after that it would stop passing VOIP packets (ran tcpdump on the server and watched them stop). If we ran VOIP over another port it would work (but had different issues related to changing around 50 phones so we only used it for testing). There were no options to disable SIP_NAT, nor any other settings that would fix the problem. Since this ISP also provided their own phone service I found the whole debacle rather anti-competitive. They simply have no interest in contacting the modem vendor and having them fix the problem.
We ended up supplying our own modem and router in this case and the problem was resolved.
