CAPTCHA (http://drupal.org/project/captcha), ReCAPTCHA (http://drupal.org/project/recaptcha), and any other flavor of CAPTCHA module including those that ask questions instead of using images/sounds.
CAPTCHAs of all kinds are inherently inaccessible to various groups of people, and, further, discourage participation even by those who have no disabilities or limitations. [Note that modules that merely hide CAPTCHAs from sighted users, like BOTCHA (http://drupal.org/project/botcha), are still a problem and should be avoided.]
When posting is restricted to known authenticated users, you shouldn't need anything at all.
Otherwise, if actually having spam problems, consider Akismet (http://akismet.com/)—via the AntiSpam module (http://drupal.org/project/antispam)—or Mollom (http://drupal.org/project/mollom) or a similar service. (Mollom still involves CATCHPAs, unfortunately, but only if it can't make a determination based on text analysis and/or user reputation. In practice, though, most legitimate users never see the CATCHPA with Mollom.)
Content Templates, aka Contemplate (http://drupal.org/project/contemplate) While very useful for site developers seeking more control over content presentation, these templates use PHP code and so increase the difficulty level for future administrators. When this level of control really is needed, a better approach is to make use of custom theming (subthemes) and/or modules.
Same goes for any other module or submodule (or option within a module) that involves entering PHP code through the Drupal interface. If you truly need to use PHP, then you truly need to either create/edit a subtheme or else write a custom module.
Yes, this means you should always leave the optional core module PHP filter disabled! (In any case, allowing users to use PHP is even more of a security risk than allowing them to use Full HTML. Just Don't Do It.)