Any replacement would also need the ability to route traffic, and subject to similar risks. A "pre-push" testing simulator might be easier than throwing out BGP.

I recall watching a Microsoft talk where they explain how they do exactly this.

This was an iBGP issue, not eBGP.

It is entirely possible to cause a similar problem with OSPF or (lol) IS-IS, with the “right” misconfiguration and route metrics.

It’s not BGP, it’s the immature tooling around it as far as simulating changes, etc.

Any other tool that allows you to announce connectivity will have the same problem. In this scenario it was still even legitimate routes, it just was too much for their specific link to handle.

I don't know how much better Juniper's stuff is, let alone Cloudflare's specific setup, but classic Cisco IOS gear's approach to batching, pretesting and merging configuration changes on mission-critical network infrastructure is basically "f*ck it, we'll do it live on the command line". Real '80s stuff, not far removed from "classic" Unix man-with-a-beard-and-a-Telnet-session configuration management (though the command line largely keeps outright syntax errors out of the config, and the (Nearly) One Big Config File makes basic restore-from-backup relatively straightforward.

Used to work on a bbone at an ATT competitor, used Juniper in the core. There was a lot of talk and sales too about SDN and the future of networking being all automated, but in the end there was always problems that needed a brain and an ssh session to fix

"BGP is a liability to society" seems a bit polarizing. Any system when told do to stupid stuff by a human via configuration will usually do stupid stuff. The right answer isn't to replace the underlying system.