Re: The real culprit
Mmm, I'm not the OP, but much as I'd love to, no, I can't agree.
Setuid/setgid is an elegant solution, but only if you overlook the lack of granularity in the *NIX security model. Their existence is proof of a failed security model, incapable of expressing a set of privileges for a process's execution. The fact that many setuid/setgid programs are or have been vectors of attack, including particularly complex ones such as mail transfer agents or sudo which otherwise have no means of performing their required duties *, does appear to suggest that while in theory setuid/setgid bits should provide the means for programs to be "Gatekeepers", as you put it, frequently they appear incapable of it. That's why we have the (I would argue still insufficient) POSIX "Capabilities" and the ACLs which make it possible for programs to limit the damage they can cause by setting up their privileges at startup.
I agree with you that Apple made a stupid mistake here; it was probably a silly oversight of a development feature or something, as suggested elsewhere in this thread. Modern OSs now ignore LD_LIBRARY_PATH or similar when the program is setuid/setgid; they also forbid signals or tracing. The kinds of mistakes made in setuid/setgid programs are probably only noticed at all because, let's be honest, so much of the remaining, unprivileged code (that is not setuid/setgid) is written with such a rosy view of the world, and the knowledge that a mistake really *can't* result in complete system compromise.
* I refuse to use sudo on non-Apple systems, and I believe MTAs should use the submit protocol to accept mail and the traditional "sendmail" binary should be a regular program, sans setuid/setgid.