Focusing solely on the (claimed) security benefits. There are multiple elements to this. I'll address each in turn.
Robustness against attacks that utilise malformed requests. The thinking here is that the reverse proxy does a better job of rejecting malformed requests and therefore does a better job of defending against attacks that depend on the server incorrectly handling the invalid request. In my opinion (as a Tomcat committer) I do not support this view in the case of Tomcat. Where it could apply is if you are using something (doesn't have to be Java based) that isn't intended to be internet facing to host your service. Then fronting with a reverse proxy makes sense.
Simpler TLS configuration. Certainly true historically when certificate authorities tended to provide certifications only in PEM form the conversion process to a Java KeyStore was not well documented. There have been improvements across the board on this. Certificate authorities are providing Java KeyStore specific instructions, Java itself is moving away from KeyStores to PKCS12 and Tomcat can use certificates in PEM format (the same format httpd uses). In my view this point doesn't carry much weight these days.
The reverse proxy offers more configuration options. This is generally true. If you need to block a header, integrate with an external authentication and authorisation system, modify a response then while you can do all of the above with Tomcat, you will need to write some code to do some of these things in Tomcat that you can do with configuration in the reverse proxy. How important this is to you will depend on what it is you are trying to achieve. One benefit I have seen is that when a new vulnerability emerges, you can often configure the reverse proxy to block the attack (e.g. with modrewrite) more easily than Tomcat.
The counter argument is that by adding a reverse proxy you are increasing the attack surface. Now you need to worry about vulnerabilities in the reverse proxy as well as your Java component.
You also need to ensure that the reverse proxy is configured correctly - especially if the reverse proxy is terminating https and then using http to the back-end. You need to be very careful to ensure that the back-end knows which requests were received (by the reverse proxy) over https and which over http otherwise you'll open yourself up to a bunch of potential vulnerabilities such as leaking secure session IDs over http.
Generally, it is probably more important to stick to what you know. If you are an experienced httpd administrator who is happy setting up httpd instances securely then you are more likely to end up with a secure configuration if you proxy through httpd rather than try and configure something you don't know. Likewise, an experienced Tomcat administrator is likely to end up with a better result with just Tomcat rather than adding an unfamiliar reverse proxy.
Overall, I suspect that the non-security arguments for using a reverse proxy (load-balancing, exposing multiple services through a single hostname) are likely to drive the decision whether or not to use one.