The Publishing Portal is designed to be used as an Internet Presence Site. It
is restricted to using simple Publishing sites  as child sites and doesn't have
access to all the list and library types available in the Collaboration Portal.
Other child site  types and the full range of list/library types can be made
available in a Publishing site by adjust configuration and turning on Features,
but they aren't there out of the box. the Collaboration Portal is designed more
for use as an Intranet site where users will be creating their own pages of
content (Publishing). It includes all the normal Collaboration features out of
the box and includes a number of custom sites for things like a centralized
Document repository, Reporting Site, and an alternate way to find sub sites
(Sites Directory).

What you have proposed would probably be best built from a Publishing Portal
after the Team Site is added back in as an available Site Definition. (You can
do this in the Site Settings page of the Top level site using the Site Templates
and Page Layouts link). You will also want to turn on the TeamCollab Site
Collection Feature to make all the Lists/Libraries available. Otherwise your
setup is a matter of setting up Anonymous access rights on the Child sites
appropriately.

For security reasons, please let me know
if what I described below is the best approach to avoid anyone
accidently putting something on the internet:

Main Top site  - Publishing Portal - Anonymous Access
-> Team A external Publishing sub-site - permission from Main Site
-> Team A internal  Team sub-site - use unique permission
-> Team B external Publishing sub-site - permission from Main Site
-> Team B internal Team sub-site - use unique permission

I've read many SP articles and some SP books, but none seem to really
get into how to architect a Portal site with many Team sub-sites.
I'm not sure if this is a good practice. So, if you have a better
ideas how to architect this Portal site, I would greatly appreciate
your input. Also, if you have any documention you can direct me too,
that would be appreciated too.

This approach will work and the use of two sites  will make it easier to keep
things that should be separate away from the Internet. However, the design will
lead to the need to duplicate material that should be on the Internet. I would
probably design it as a single set of Team Sites where specific lists and
libraries are duplicated and secured or exposed to the Internet. Then you could
use the SendTo command on the internal  list/library to send content  to the
list/library exposed to the outside. I would also setup the external site  as an
Extended Web Application Zone with a different URL. This tends to be better for
Anonymous Access since it forces Authentication when you log in to the Internal
URL and does Anonymous Access for the external Url. Finally, I would setup a
Web Application permission Policy on the external Url limiting all users to Deny
Write. This would prevent users from accidentally adding content if logged in
through the external URL.

But no matter how you architect it you will have to train the users not to
deploy content in the wrong place or things could be exposed to the Internet
unecessarily.