Apparently, tcp_syncookies introduces more benefits than disadvantages.
Instead of the typical speculation on random blogs, perhaps we could consult "the source":
With the updates for IPv6 and modern TCP option schemes syncookies appear primed to keep providing sweet relief in their somewhat esoteric networking security niche.
The linked article quotes some experiments and draws some conclusions:
Willy Tarreau: My tests on an AMD LX800 with max_syn_backlog at 63000 on an HTTP reverse proxy consisted in injecting 250 hits/s of legitimate traffic with 8000 SYN/s of noise.[..] Without SYN cookies, the average response time was about 1.5 second and unstable (due to retransmits), and the CPU was set to 60%. With SYN cookies enabled, the response time dropped to 12-15ms only, but CPU usage jumped to 70%. The difference appears at a higher legitimate traffic rate.
Ross Vandegrift: Under no SYN flood, the server handles 750 HTTP requests per second, measured via httping in flood mode. With a default tcp_max_syn_backlog of 1024, I can trivially prevent any inbound client connections with 2 threads of syn flood. Enabling tcp_syncookies brings the connection handling back up to 725 fetches per second.
This data compellingly supports the continued value of the syncookie and that position seems to have won the day. The IPv6 syncookie patches are now queued within the network 2.6.26 development tree.
Also, according to CentOS' documentation, this is used in an adaptive way, possibly in order to avoid disrupting legitimate traffic:
If the number set in tcp_max_syn_backlog is reached, this parameter kicks in so that your server isn't unreachable due to connections waiting for an ACK that will never come.