As you all may know, content deployment is a powerful feature in MOSS 2007 (this concept has been brought over from CMS 2002). With almost any site, you need authors to actually create and edit the content that the target users will see. If the site is internet accessible, then there are a host of security concerns associated with the content/application etc. So for an external facing site, it is best to have at least 2 separate farms - an internal farm where authors can create, modify and approve content as well as an external farm where the content will be pushed out to for external user viewing. There can also be three farms (authoring, staging and production) where the content follows the authoring --> staging --> production chain. The staging farm can be used to "stage" the content so that it can be reviewed one final time before it is pushed to production.
We recently reviewed the different farm topologies and decided to go with the 3 stage approach (authoring, stage, production). I will list the advantages and disadvantages of 2 vs. 3 stage topology as they applied to us. Keep in mind that your situation might be different as you might have different constraints.
Two Stage topology:
1) Simple content deployment strategy. Users approve pages in authoring farm and that content is pushed to the production farm.
1) Stage does not exactly mirror production in terms of content.
2) If business users need to view content, they must view it on the authoring server which might not have the same links or the same look and feel as production. (the master pages might be slightly different for an optimized experience etc.)
Three stage topology:
1) Stage is always a complete replica of production, in terms of content and applications. This will be imperative for testing a production-like environment, which may not be feasible on the internal farm.
2) In case of a disaster on production, you can simply change the external DNS entries to point to stage while you bring back production.
3) Authors and business users will get another chance to preview content on stage before it is pushed to production.
1) More complicated deployment strategy.
2) We will need to ensure that stage is used to review content or it becomes a redundant deployment hop.
Thus the 3 stage topology makes more sense for our business case. A recommendation I would make is to make sure you design your infrastructure correctly - ensure that you allocate budget for a dev, test, stage and production farms. This is the right way to do things and can make your life easier over the long term.