I vote for using many site  collections because of the following:

1. You can use stsadm.exe to backup each site collection  individually
having a full-fidelity backup including all security and personal
settings. You have to use smigrate.exe to backup subsites, but
smigrate.exe doesn't restore security by default. Smigrate also takes a
lot longer for backups.

2. You have some control of using content  databases to put  site
collections. You can even force a site collection to be created on its
own content database. It takes a little tweaking to get it to work  like
you want. If you use all subsites, then you will eventually have one
gargantuan database.

3. You will have some issues moving and/or restoring subsites  because of
#1 and #2 above.

We started off with all subsites two years ago, but are transitioning to
site collections because of issues above. We now use multiple portals
and managed paths for organization.

So, based on what you've said here, would the same go for
considering when to create subsites  for teams? For example, if I
create a team site  for a team (instead of a cluster), should I make
a site collection  for their "public" site that all staff can read,
and a separate site collection for their team "private" site (for
all team collaboration, planning, etc.)?

What do you think? I could see a potential problem w/ having a
public site and using a subsite to start the "private" work  for the
group (which is what I had been planning  to do). They will likely
start creating  subsites and meeting workspaces, and if some day they
need to delete the public site (?? for some reason), there would
have to be a way to back up the 1st subsite and all of its
subsites/workspaces to move them "up" as their own site collection.
I know how to do this w/ frontpage, but it doesn't keep any
permissions info or personal settings (as you noted in your message).

Does this make sense? Sorry- I don't know if I'm saying this right.

This is just such a hard decision to make since I've heard arguments
for not having too many site collections, too.

We do the same thing with having a public and private site  for teams.
The public site contains general documentation with few details, and the
private site contains the "meat" with very technical information. I
would recommend using separate site collections with different security
settings. For example, our Information Technology Group (ITG)
Operations dept. SharePoint websites are setup  as follows:

http://itg/operations/home (ITG Operations home site linked from portal)
http://itg/operations/desktop (ITG Operations Desktop Support site)
http://itg/operations/support_center (ITG Operations Support Center
site)
http://itg/operations/data_center (ITG Operations Data Center site)
http://itg/operations/systems (ITG Operations Systems site or public
site)

All sites  listed above are site collections on the ITG portal. The
systems site contains public information for management and others with
very general information. There are many ways to setup your site
structure (taxonomy), but the method above works best for us. I
originally approached SharePoint like I was setting up a folder
structure on a file server. For example, our ITG Server Support
websites were setup as follows:

http://itg/sites/server
http://itg/sites/server/infrastructure
http://itg/sites/server/enterprise
http://itg/sites/server/messaging

We then found out that we had limitations with backup and a large
database size because all sites are subsites  of server website.
Therefore, we redesigned the structure to be:

http://itg/server/home
http://itg/server/infrastructure
http://itg/server/enterprise
http://itg/server/messaging

To get this design, setup "server" as a managed path, and create
separate site collections. This is a "wide not deep" structure. This
taxonomy seems to work  the best for us, but you may need a different
structure. I would ask others for other SharePoint site design ideas
before creating  your site structure because it can be difficult to
change down the road.

Anytime you need a new collaboration space, you can use a new site
collection. In larger companies, there can be 10's or even 100's of new
site collections every day.

So, part 2 of my question is this: what are some tips for keeping
sites organized, findable, avoid duplication of documents...etc. My
brain is still stuck on info architecture, so flat is something that
sounds bad to me.

I imagine, as said that a company is now doing, I could use
portal to keep an organized list of sites  and set up a kind
of "pretend" architecture/hierarchy there.

I'm so used to dealing w/ folders and subfolders that this is hard
for me to wrap my head around.

I recently took 7-8 sites and merged them under one "umbrella" site.
This was for our AMS project, and there are several different teams
working on different modules. I made the top site  public and it
holds info and documents on progress, etc., for the entire staff to
read. The other sites are sub-sites w/ different permissions. I did
this since they are all part of the same project. Would you
recommend that these actually be (as they once were) individual site
collections?

I'm wondering now when you would use sub-sites.

Use the sites  Directory to organize your sites. That's what it's for.