You're right that the article doesn't delve into the technical specifics - but the report the article is describing, available via this link provides more details.
The essence of the issue is that DDoS attacks are attacks against capacity and/or state. Even the largest firewalls commercially available or that one can build have limited state-table sizes.
Placing stateful firewalls in front of client access networks makes sense - when your Web browser requests the TCP/IP stack on your client device to set up a three-way TCP handshake with example.com, there's an outgoing SYN request which traverses the stateful firewall, and the stateful firewall makes a note of this in its state table. When the SYN-ACK response comes back from the example.com server, the stateful firewall checks to see if there's a corresponding outbound request and that the incoming response conforms with the firewall policies - if the answers to both questions is 'yes', then the firewall passes the server response packets. If the answer to either question is 'no', the stateful firewall drops the inappropriate server response.
When we're talking about Web servers, DNS servers, et. al., however, basically every incoming request is unsolicited - therefore, there is no state to inspect. This is why it makes zero sense to put a stateful firewall in front of servers.
Instead, the server OS and apps (Apache, BIND, sendmail, whatever) should be hardened, tcpwrappers should be deployed on the server to provide onboard stateless policy filtering, and stateless Access Control Lists (ACLs) should be implemented on your hardware-based routers and/or layer-3 switches in order to enforce network access policy - e.g., allow TCP/80 and TCP/443 for a standard SSL-enabled Web server, allow UDP/53 and TCP/53 for a DNS server, etc., and then disallow anything else from the outside.
Here's a .pdf presentation from a recent NANOG conference which makes the same point.
When stateful firewalls are used to enforce these polices which ought to be enforced by stateless ACLs per the above, the state-table limitations of even the largest firewalls form a significant DDoS chokepoint. Attackers can craft well-formed attack traffic which will conform to the firewall rules, but which will 'crowd out' legitimate requests from users, and which in many cases causes an error condition on the stateful firewall which causes it to stop forwarding packets altogether. This leads to a DoS of the firewall itself and all the servers behind it.
I've seen this over and over and over again, even with very large firewalls. It's far easier to DoS the largest firewall in existence than it is to DoS well-tuned, hardened server TCP/IP stacks.
Servers should be protected from DDoS attacks via source-based remotely-triggered blackholes (S/RTBH), flowspec, and/or intelligent DDoS mitigation systems (IDMS) specifically designed for this application.
Load-balancers are also a DDoS state vector, but in many environments are a necessary evil. When they must be used (note that there are many ways to achieve clustering/load-balancing without making use of single-point load-balancers), they must be protected by the same stateless ACLs in terms of enforcing network access policy, and must furthermore be protected from DDoS by S/RTBH, flowspec, and/or IDMS.
'Application-layer firewalls', with their 'protocol inspectors', and so-called 'IPSes' are even worse. They carry even more state, and the protocol inspectors offer a broadened attack surface for exploitation and device compromise (you can find numerous examples of publicly-acknowledge buffer overflows, etc. which comprise security vulnerabilities in the inspectors of both commercial and open-source firewalls and 'IPSes'). Consequently, they fall over during even a moderate DDoS attack even more quickly than the equivalent basic stateful firewall.
To comply with the poorly-crafted PCI DSS standard, on-server 'application firewalls' like mod_security fulfill the firewall requirement.
If you're forced by poorly-thought-out policies/regulations to put a hardware-based stateful firewall in front of your servers, you should go ahead and enforce network access policies in the form of stateless ACLs on the hardware-based routers/layer-3 switches which are northbound of the firewall, and then protect the firewall against DDoS via S/RTBH, flowspec, and/or IDMS.
None of the popular sites/servers you make use of on a daily basis have stateful firewalls in front of them - at least, the ones that stay up, heh. Here's a link to a .pdf presentation which makes note of many of the above points, and points out that firewalls were the first thing to fail in the RoK/USA DDoS attacks in 2009, by way of a high-profile example (these failures happen daily, this is just one notorious example; also note that the RoK/USA DDoS attacks were neither high-volume nor sophisticated).