Scalability - You can load balance multiple instances of your application behind front end server. This will allow you to handle more volume, and increase stability in the event one of your instances goes down.
Security - Apache, Tomcat, and Glassfish all support SSL, but if you decide to use Apache, most likely thats where you should configure it. If you want additional protection against attacks (DoS, XSS, SQL injection, etc.) you can install the mod_security web application firewall.
Additional Features - Apache has a bunch of nice modules available for URL rewriting, interfacing with other programming languages, authentication, and a ton of other stuff.
Clustering - By using Apache HTTP as a front end you can let Apache HTTP act as a front door to your content to multiple Apache Tomcat instances. If one of your Apache Tomcats fails, Apache HTTP ignores it and your Sysadmin can sleep through the night. This point could be ignored if you use a hardware loadbalancer and Apache Tomcat's clustering capabilities.
Clustering/Security - You can also use Apache as a front door to different Apache Tomcats for different URL namespaces (/app1/, /app2/, /app3/, or virtual hosts). The Apache Tomcats can then be each in a protected area and from a security point of view, you only need to worry about the Apache HTTP server. Essentially, Apache becomes a smart proxy server.
Security - This topic can sway one either way. Java has the security manager while Apache has a larger mindshare and more tricks with respect to security. I won't go into this in more detail, but let Google be your friend. Depending on your scenario, one might be better than the other. But also keep in mind, if you run Apache with Tomcat - you have two systems to defend, not one.
Add-ons - Adding on CGI, perl, PHP is very natural to Apache. Its slower and more of a kludge for Tomcat. Apache HTTP also has hundreds of modules that can be plugged in at will. Apache Tomcat can have this ability, but the code hasn't been written yet.
Decorators - With Apache HTTP in front of Apache Tomcat, you can perform any number of decorators that Apache Tomcat doesn't support or doesn't have the immediate code support. For example, mod_headers, mod_rewrite, and mod_alias could be written for Apache Tomcat, but why reinvent the wheel when Apache HTTP has done it so well?
Speed - Apache HTTP is faster at serving static content than Apache Tomcat. But unless you have a high traffic site, this point is useless. But in some scenarios, Apache Tomcat can be faster than Apache httpd. So benchmark YOUR site. Apache Tomcat can perform at httpd speeds when using the proper connector (APR with sendFile enabled). Speed should not be considered a factor when choosing between Apache httpd and Tomcat
Socket handling/system stability - Apache HTTP has better socket handling with respect to error conditions than Apache Tomcat. The main reason is Apache Tomcat must perform all its socket handling via the JVM which needs to be cross platform. The problem is socket optimization is a platform specific ordeal. Most of the time the java code is fine, but when you are also bombarded with dropped connections, invalid packets, invalid requests from invalid IP's, Apache HTTP does a better job at dropping these error conditions than JVM based program. (YMMV)
Wasted opportunity on this page. Ended up here after a search for apache + haproxy + nginx and which would be better as a frontend load balancer..... and the article doesn't mention haproxy or nginx once in the content - all just apache.