I am about to embark on a a major re-engineering and redesign of an
informational web site  where there is frequently new content, and
every bit of content has to be presented a variety of different ways. 
Given the offerings of my ColdFusion-based hosting environment, which
I cannot change, I've narrowed my strategy down to two options... I
can either store my content in a SQL database and create a series of
CF templates that then query the database to pull the content and
display it in the proper format.  OR, I can store all my content in a
series of XML files, create XSL Templates, and just use CF to pull the
proper XML/XSL files and marry the two together for display.  After
scanning several books and scouring the web, I still don't really have
a grasp of which is the better path... Or if there's an even better
3rd option I'm not considering. ("Better" being the "best" balance of
speed, performance, manageability, expandability, and conformation to
standards.)   Thoughts?

Hmmm.  I'm not sure one can really put the two alternatives on a level
playing field, but some thoughts about why this is so may be helpful
to you in making a design decision.

One way to look at SQL vs. XML as a data repository is that SQL, with
its relational table approach, is hands down the winner in terms of
storage for significant amounts of comparable data.  SQL syntax,
derived from first-order logic/universal algebra, is very powerful for
doing batch actions (doing the same thing to a lot of different
entities with common instructions).

XML, on the other hand, with its emphasis on a tree-based approach, is
often more apt for representing individual "entity" data in an easy to
use (e.g. by XSLT) format.  Navigation of the tree is a bit tricky if
you are used to thinking in SQL/relational terms, but once you get the
hang of it, the recursive possibilities of XSLT are nearly addictive.

So perhaps a case can be made for maintaining the application data
through a SQL database (possibly using ColdFusion to support a
transactional frontend for Web editing/input) and at the same time
"publishing" the data to consumers (without an ownership role of the
data) using XML files to represent individual entities.  [Of course I
don't mean to imply the design decision need be quite this stark;  XML
documents can easily collate multiple individuals as branches under
the root, and many SQL database engines are adept at extracting rows
from multiple tables related to a "common key" entity & presenting the
resulting "join" in XML format.]

regards, mathtalk-ga