The more I read about all the planning one needs to do prior to
install/configuring, the more confused I get about this product. ;0)

What I'm trying to do now is to best determine how we want to set up our
collaboration portal. This is the rough structure I have now:

Team.ourdomain.com web app
- region 1 site collection
- HR site
- HR sub-site
- etc.
- IT site
- management site
- etc.
- region 2 site collection
- HR site
- HR sub-site
- etc.
- IT site
- management site
- etc.
- region 3 site collection
- sub region 1 site
- HR site
- HR sub-site
- etc.
- IT site
- management site
- etc.
- sub region 2 site
- etc, etc...

11-12 region site collections in all, each dividing sites into
departments, or even sub-regions, then departments. Each with their own
admin (I'm letting them organize their own collections any way they want
to)

From a IA/management standpoint, this seems valid.

But now I'm reading more about capacity planning and making sure your
DBs aren't huge and adding quotas and all that. This is the part I don't
get.

Joel Oleson's comments on this:

-----------------------
blogs.msdn.com/.../tips-on-site-collection-s
izing.aspx

In WSS 3.0/MOSS 2007 I recommend you pick a maximum site collection
quota of no larger than 15GB, excluding the top level site collection
and to move sites to dedicated databases where they need to grow beyond
this.
-----------------------

I really have no practical way of knowing how large each region's site
collection may be, though I have a hunch it will easily get over 15gb.
What then?

Should I wait until then, then pluck out sites from each collection and
then move them to a new top-level site collection in a separate DB? What
are the issues of a region having their content split into two
collections? I assume that's going to make it harder to share date
between departments?