I disagree with that. Apache's defaults on most distros isn't secure. Even 'enterprise' level distributions often fall into the following traps when packaging Apache:
1-> auto indexing enabled (should be disabled)
2-> user directories enabled (should be disabled)
3-> server signatures 'on' (should be 'off')
4-> server tokens set to 'full' (should be 'prod')
5-> hidden (dot prefixed) files not always blacklisted as unauthorised files in Apache config
6-> same as above for editor specific back up files (eg file~). But this is only an issue for people who bulk upload or edit files on the live server (very naughty).
7-> having less optimal SSL configurations (Apache's default SSL set up isn't PCI compliant).
(IIRC there's a couple of other Apache tweaks, but that's just off the top of my head)
Then you have issues with PHP (eg logging to STDOUT so web users can view PHP errors).
And that's just covering the webserver configuration. There's still holes that need plugging if you actually want to run a secure web server; one of my favourite tools for that is using fail2ban which will auto-blacklist IPs in iptables (Linux firewall) based on if certain attacks are detected. For example it can prevent brute force attacks on SSH brute force attacks (which negates the need to run denyhosts as recommended in the article), HTTP auth, FTP, mail servers, etc.
And touching on SSH, many data centres will enable root log ins on their OS pre-installs by default. Your first job on any such box will be creating a user account and then disabling root log ins (PermitRootLogin no -> /etc/ssh/sshd_config).
Then there's a whole stack of optimisations you can run on iptables to adaptively prevent port scanning, forged TCP/IP packets and such like.
Also many distributions ship FTP, which is insecure by default. Anyone sys admin requiring FTP hosting would be better off using a chrooted SFTP environment (so the security benefits of SSH plus the sandboxed (chroot) environment that FTP often benefits).
Let's also not forget the plethora of internal services (databases, MTAs (mail servers), etc). If you're reading this article then you're probably not a trained systems administrator or not working for a large enough company where each server is running in it's own environment. Thus your MySQL / Postgre / whatever databases are running on your webservers. So you need to ensure that your database is only listening on localhost (127.0.0.1). Same applied for your MTA, unless you are intentionally providing a mail services (it is advisable to have an MTA installed even if you're not providing mail services because you can then set up daemons like fail2ban to automatically e-mail you when attempted break ins happen; which will in turn allow you to spot any determined hackers and permanently ban their IP from your box).
And lastly, if you're really paranoid, run your webserver inside a Linux/UNIX container (FreeBSD Jail, Solaris Zone, Linux OpenVZ) instead of inside a virtual machine as there have been hacks where attackers can break out of the VM and gain access to the host system (as of yet, I've not heard such attacks from containers, but if anyone has any evidence of that then I'd love to know). Running inside a container will give your webserver the sandboxed environment to work with plus an easy route for backups / snapshotting meaning minimal downtime and data loss should the worst happen and your server does become compromised.
(source: http://www.youtube.com/watch?v=hCPFlwSCmvU - it's a plugged vulnerability, but it will give you an idea about the kind of issues VMs face when compared to containers)
In short; distribution's don't ship secure defaults. They ship a happy medium between usability and security. However if you have an internet facing box (particularly one not hidden behind a hardware firewall, as many budget set ups are not), then the happy medium isn't secure enough.
