The article's conclusion is correct in a large scale environment, but it does not show any of the steps that get you there, or alternatives to putting everything behind a stateful firewall. Really, the thesis statement should have been "External facing servers should not be behind stateful firewalls".

In any large scale customer facing deployment, you have to leave a piece of the application facing the customers. However, you are best off limiting what is on that host (or hosts, as you are probably talking a load balanced solution) to just static content and calls to the application/database servers - which can and in many cases should be behind stateful firewalls. Protecting the customer facing box becomes an exercise in limiting attack scope - stateless router ACLs, hardening the box, and the like - things that protect against packet/session floods that may not fully saturate your actual bandwidth but could still cause a firewall to collapse under the number of new sessions that are being created/denied.

In short, make your external facing application be multi-tiered (preferably with redundancy) to achieve higher uptime and better resiliency against external threats. In my experience this model does seem to cause internal incompetency threats to break your application more often, however...

Except this is no longer true in a full-duplex world, you can approach 99% utilization on Ethernet at full-duplex. At the time token-ring was competitive, full-duplex Ethernet was just emerging. While IBM's marketing and some of the complexity of token-ring hurt it, what really killed it was the widespread emergence of full-duplex ethernet switches which basically eliminated the under-utilization problem while not having the complexity of dealing with a token-ring network.

Except they are not "throttling" you, they are just giving you lower priority IF you use over 80% of your bandwidth for 15 minutes AND the whole segment is over 70% utilization. This means that grandma can still get her mail when you are seeding the new release of Ubuntu, but you "lose" bandwidth if you actually hit 100% congestion.

Cable services are shared for the last mile between the homes that they pass. For Comcast, the last numbers I saw (from the fairshare information threads) were ~250 homes per downstream. The higher the per-household usage, the more they have to split up that grouping - which requires putting more cable in the ground, setting up equipment, etc.

This is the bandwidth crunch the cable companies have, not the core of the network. The article actually does not address that fact at all, and seems to assume infinite edge bandwidth with limited core bandwidth. This is true in an enterprise network, but is not true in a cable network today.