I'm not an administrator  but I play one on TV. So, I don't hold any hard
beliefs in this area, but I don't think that you want "One account  per
application pool". Generally, each active application  pool that you
create consumes at least 100 MB of RAM that grows to accommodate usage.
Unless there is a strict demand for memory/thread affinity, I would use
one common application pool. Also, I don't personally see value in
having all those separate service  accounts. But I'm a developer that
generally authenticates as the Administrator and uses Administrator for
all my service accounts. So, what do I know.

My standard farm  install would have 3 app pools,
with 3 distinct accounts:

Farm account  (Central Admin App Pool)

SSP Account (Shared Services App Pool)

Community Account (Shared App Pool)

The primary reason, in my mind, for creating additional app pools is to
trap errors introduced by your developers.

This section starts with a table of 6 accounts  for MOSS (4 for
WSS) that you can pre-create.

I usually just use 3 accounts... I have been uninstalling and
reinstalling and literally "trying" to break my dev install of MOSS
to document any anomolies that I find, and I've never had a problem
with just the 3. I use svc_spadmin, svc_sqladmin, and svc_test.

I go the route of being able to trap your developer's
errors within the confines of an application  pool.

I usually use the following:

Central Admin
Search
Crawl
SSP

And then for each additional web application, they each get their own.

Overkill? Maybe, but when you've got a horde of customers hitting your
site, you've got to do what's best for them right?

"trap your developer's errors"

I guess that's why us devs only need one app pool. We don't make errors.

Maybe it's more trapping the developers.