ONET.XML is only processed when the area/site is created. It can not be used to retroactively add  web parts to existing  areas/sites. You’ll have to come up with another strategy for placing the web  part on existing areas.

Is there any other way
to make these types of global  changes without creating
your own management tool or buying one such as
WinAppTechnology Echo?

I realize that this won't help your specific situation but it is good to
know. There are actually two "hot spots" in the ONET.XML file  that are
continuously referenced by each site. The first is the
DisableWebDesignFeatures attribute of the Project element. The second is the
top-nav NavBarLink (until the page  or the nav bar is unghosted). There may
be other hotspots but I have observed these.

I'd love to hear about the hotspots that people have observed in the
SCHEMA.XML file.

You can add  list definitions to the ONET and affect existing  sites (they
will show up on the Create page).

Well, unsupported (see Mike Fitz's blog on what that means) pretty much
any of the content in SCHEMA.XML is "hot" as you put it. I can
dynamically change  a field description, display name, add  a view, add a
field, etc. without any downtime (deploy SCHEMA.XML and do an iisreset
or cycle the AppPool and changes are put out to all instantiated sites).

The only area  that I've found so far that is no-touch in SCHEMA.XML is
when you change the internal name (sometimes) and most times when you
change types. Some type changes works (Most types to Text work) and
something like DateTime to Number works (because the Date is stored as a
number internally anyways) but things like changing Lookup to Number or
something will just crater your list to the point that even the OM will
throw an exception just looking at it.

Just as a sidebar, I was told that one of the key issues surrounding support for modifying site definitions after a site has been created  is what happens when list definitions are added…

I totally believe it, since support around site definitions is so limited and controversial. It is a shame too since list definitions are pretty handy and to say you must define what you will always need for a site and have it right from the get go of site definition  creation is highly close minded and limiting.

I haven't tried that but it also makes sense. I typically think about
these changes in the same way we used to think about binary
compatibility in Visual Basic COM components. We can add  and alter as
long as we don't effect the public interface prototype.