AFAIK the Debian package removes that entirely in its binary sources, so you cannot use it there. Reasoning is found in CVEs (Google has some of them, e.g. http://legalhackers.com/advisories/nagios-nrpe.txt)
One reason against this is that you cannot control the default parameters, e.g. limiting the scope of passing thresholds or additional execution parameters. “-a” just overrides anything you’ve specified locally. This is pretty harmful if you expose NRPE not only to your monitoring master, but allow customers to use that as a remote ping service for example.
The upstream readme is pretty useless, it hides the critical stuff. If you really care about security, you don’t use NRPE these days. The TLS encryption uses anonymous DH, which is predictable and shared on each binary build (meaning to say, the same binary build trust each other). allowed_hosts with IP addresses is pretty weak, IP spoofing is always a thing. IIRC v3.0 introduced the ability to use x509 certificates, still it only validates the trust chain with the same CA signing method. There’s no additional security involved with checking the certificates CN with the current connecting FQDN, and no local white/blacklist either (as one has with Icinga 2 and endpoint object configuration, or browsers which do enforce SubjectAltName checks).
A good read from a security guy: https://archive.cert.uni-stuttgart.de/bugtraq/2014/02/msg00054.html