It's not just rhetoric.

Here's my two cents on this soapbox. There are at least four reasons
(listed from least important to most important) that Mindsharp is a
"ghosted-pages only" shop:

4. Separation of data and logic. The OOB SharePoint pages  separate what
I call the plumbing and custom chrome (direct-mode page) and the data in
an elegant way. The page  is a standard ASPX page stored in the Site
Definition on the file system and all state (data and metadata) are
stored in the database. I know that it is somewhat of an "ivory tower"
position, but unghosting breaks that separation putting logic into the
state store. But maybe you aren't philosophical, so...

3. ghosted  pages are performant, unghosted  pages are not. I yield that
this is probably trivial but on a common page hit  frequently by
thousands of people every day, it could certainly prove significant. How
many of us moved from ASP classic to ASP.NET to get the 30% boost of a
compiled vs. sequentially processed page. Unghosted pages are not
JIT-compiled and are processed sequentially by the safe-mode parser
rather than JIT compiled and retrieved from memory using the .NET
parser. Ghosted has to be faster. But maybe your hardware meets that
bar, so...

2. Ghosted pages yield master page-like functionality today, unghosted
pages break that functionality today and tomorrow. SharePoint
direct-mode pages behave similar to tomorrow's ASP.NET 2.0 master pages.
Unghosted pages are stored as static snapshots of the page upon which it
was originally based and can even abort if the direct-mode page was
heavily modified or contains certain in-line script. But maybe master
pages aren't important to you, so...

1. I speculate that ghosted pages will easily upgrade from SharePoint
2003 (v2) to v3 and unghosted pages will likely fail catastrophically.
Here's why: Since unghosted pages support almost any kind of alteration
that the end user wants to make, I doubt that there will be tools that
can handle the conversion from unghosted to v3 master page. I wouldn't
want to write one. Given that most pages are unnecessarily unghosted by
an unknowing public, many will find themselves with a tremendous task
when it comes time  to upgrade. They will be sorting through potentially
thousands of pages trying to determine which pages truly needed to be
different than the direct-mode page (unghosted) and how they can be
re-customized in v3. This could add weeks or even months to some
upgrades. If we scrutinize alterations today and put them into
components (the SharePoint model) we can avoid unghosting except for
circumstances where unghosting costs outweigh the alternatives.

So, I don't specifically have the metrics  that you are looking for. But
these reasons are compelling enough for me. So far, I haven't found a
single reason that compelled me to unghost any pages in our environment.
It just isn't necessary and the cost is potentially far too high for me.
But each company must decide whether they will allow unghosting on their
own. As for me and my house, we will not unghost.

I have some extra questions
regarding this ghosted/unghosted thingy, and I hope you can shine you light
on it; Suppose I would make an template within a sitecollection, based on a
non-frontpage-adjusted subsite, I would say the template holds the delta of
the site def and the desired output.... am I right? So if that is trough,
any site created through that temaple is partially based on the site def and
adjusted according to the (databased) template. Ok. What happens if the
template is based on a frontpage adjusted subsite? Will the template not
only hold the delta, but the complete definition? Will any site created
according to this template be completely unghosted??

Great argument… very similar to our stance as well!

excellent post! totally agree with the philosophy of seperating the
presentation from the data.

All SharePoint sites, without exception, are based on a specific
underlying site definition. A Custom Template (STP) can best be thought
of as a macro that alters a site after it is created. I realize it isn't
actually a macro but it behaves like one. After a new site provisioned
using a Custom Template is created, it is 100% dependant upon the
underlying site definition (both the ID and the LCID) that the Custom
Template was dependant upon.

There is one caveat to be aware of with regard to Custom Templates and
Unghosted pages. If you unghost a page  in a pristine site, use Maurice's
Ghost Hunter to reghost the page, and then create a Custom Template of
that site. Any sites created using that Custom Template will result in
an unghosted  page being perpetuated. The reghosting process is
incomplete. So, be sure not to create a Custom Template from sites where
pages have ever been unghosted. Use a pristine site instead.