Using SharePoint Central Administration to create a Windows SharePoint
Services Top-Level site  (let's call it an Extra-portal Site Collection)
allows the creator to choose what database  the content  will live in.
Creating a Windows SharePoint Services Top-Level Site (embedded Site
Collection) from a SharePoint portal  Server will automatically reside in the
portal's database.

In fact, I think there are _at least_ four very compelling reasons to
primarily create Extra-portal Site Collections:
1. DATABASE INDEPENDENCE: Extra-portal Site Collections can live in a
separate database. This can be very useful for backup and recovery,
transaction isolation, geographical distributed sites  close to their users
but still indexed by the Enterprise Portal, database server scalability,
etc.
2. URL INDEPENDENCE: The creator can choose to use the same domain as the
portal plus a chosen wildcard included virtual directory or choose a unique
URL or both, include a separate  SSL URL or not, etc.
3. SECURITY INDEPENDENCE: Extra-portal Site Collections can optionally be
run under a unique virtual directory (IIS Web Site independence) and
therefore use a different Application Pool Identity than the portal or not.
Running under a different security content could prove to be very useful.
All Virtual Server configuration can also be done independent of the portal.
4. ANONYMOUS ACCESS: The first step to setting up anonymous access is to
enable it in IIS. If you are using embedded Site Collections then you must
enable anonymous access for the entire Portal and all other embedded Site
Collections. If you are using Extra-portal Site Collections you can turn it
on for some and leave it off for others.

The only cons to creating Extra-portal Site Collections that I am aware of
include:
1. NO AUTO-SEARCH SETUP: Search does not automatically index Extra-portal
Site Collection content as portal content. A separate content source must be
created for each Extra-portal Site Collection provisioned. That may not be
all bad because Search isn't indexing any content that it isn't explicitly
configured to index. Lots of stuff  can creep into Windows SharePoint
Services Sites that the enterprise may not want to index.

Portal Listing to Extra-portal Site Collections can be created  and they, in
turn, can link "Up to" the portal.

I typically recommend that people  use Windows SharePoint Services for
everything unless SharePoint Portal Server is absolutely mandated. What
follows is my thumbnail list of reasons that I think compel people to use
SharePoint Portal Server listed more or less in the order that people seem
to rank them:
-Enterprise Search (vs. Site search)
-My Site
-Areas can be hierarchically moved around whereas WSS Sites are fixed
-Areas can have Web Parts that reflect an Audience
-Areas can be set to expire at a given date (and other metadata)
-Multiple Areas can display the same content
-Listings (super links with metadata like expire date)
-Some unique Web Parts (Links for You, News for You, Sites I've Created,
etc.)
-Areas generate dynamic Top and Left nav base on Area hierarchy (most
people don't like this "feature") vs. the WSS Quick Launch bar (it too is
limited in usefulness)
-Topic assistant

Basically, people would go to their SharePoint portal for the same reason
that they go to an Internet search engine, not to find information on the
portal but to locate information that the portal can point them to.:
1. To search for content that they aren't sure where to find 2. To browse
for content that they aren't sure where to find

I like to say, people don't typically go to Google to see what Google
contains, people go to Google to find other sites to visit that contain what
they are looking for. Google is just the doorway to information, not the
house.

STYLE INDEPENDENCE (more relevant on why to use a Site over an Area): Sites
can be templated, styled, and can generally adopt to any look and feel that
a company desires. SharePoint Portal Server and Areas cannot or at least not
nearly as easily. There isn't anything that FrontPage can't do with a Site
but FrontPage has real trouble with Areas (at least in V2). WSS Site and
List templates typically share the same Site Definition making them
relatively easy to share, each Area has its own Site Definition and
therefore makes sharing solutions difficult.