As usual, another discussion of regulation of software safety or security ignores real-world, past/present schemes regulating software safety or security. Regulations that worked in terms of vastly improving both. Then, after ignoring that, the author claims no benefit to government stepping in with regulations. Let's quickly look at those instead to see what was done.

For security, Walker's Computer Security Initiative mandated the DOD would only buy computer systems if they were secure to an appropriate level. The initiative included (a) guidance for improving security through whole lifecycle, (b) an evaluator (NSA) that would have to certify that guidance was followed w/ pentesting of anything claiming high-security, and (c) a requirement that vendors wouldnt get paid unless their products were certified. Lo and behold, the market suddenly produced half a dozen products with vastly better security than before plus a few that seemed free of vulnerabilities even down to covert leaks of information. The TCSEC had issues but fundamentals were sound of picking something businesses could understand, evaluating it, ensuring assurance of correctness, and financially incentivizing them. The bribes companies paid to Congress to get a change to COTS acquisition, uncertainty in export restrictions, NSA competiting with private sector under MISSI, and no demand in mass market for things that were actually secure killed the market for high-assurance security. Got watered down to mostly paperwork in Common Criteria w/ very few systems going for the standards that are actually secure (EAL6/7) and usually for select components in systems. Yet, the process worked with security improvements across the board w/ a few, highly-secure systems delivered.

On safety side, let's look at DO-178B (now C) for aerospace. They require carefully documented requirements, design, and so on with code proven to match it with code review and rigorous testing. It has to pass certification with no problems for them to make money on it. Re-certification is expensive. That led to vendors throwing as much QA as possible at their code which they simplified as much as possible. A whole ecosystem sprang up for safe languages, drivers, protocols, and so on. Also, tools for automating testing, supporting reviews, semi-automated generation of code, etc. The quality of all of this is much, much higher than typical of mainstream proprietary or FOSS apps. So, again, the sensible regulations worked.

That's twice it's happened. It could happen again for Internet security if it was a combination of reasonable protection profiles for certain classes of devices with focus on assurance of design, implementation, configuration, and maintenance like in TCSEC or high EAL's of Common Criteria. Just requiring memory-safe languages, POLA, safe/secure-by-default configuration, using components with few CVE's, fuzz testing, and secure authentication for admins would go a long way. On ISP side, the ability to detect DDOS's and temporarily throttle or cut off the nodes sending them until they've gotten their act cleaned up. This filtering could be done right in the ISP's modems or routers.

So, we can do a lot more than the OP lets on. Regulation on safety and security has worked twice. It's still working on safety side. We should do it again on security minimizing paperwork, expensive evaluations, etc to focus on minimum subset of features and assurance activities that get most of the results. 80/20 rule. Also, allow new methods or tools so long as they've previously proven to work on whatever they claim to do.