As far as avoiding the database, the greatest leverage will come from caching select queries (i.e. memoizing them using the appropriate ACS utility routines) used to build pages.
This is something that happens a LOT, and often include joins, which are relatively expensive.
Insertion of new stuff into the database is relatively rare, and doing a select nextval() is one of the fastest things you can do in Postgres. No table is referenced (unless the code's still using our "dual" view which was added to ease porting of Oracle code). No "where clause" means no poking at an index to extract rows, etc. It is really a very fast database operation that in essence doesn't really "hit" the database.
And the time spent doing the "select nextval()" is going to be absolutely swamped by the time to do the "insert" that follows.
So while I agree that avoiding the DB is a good thing, in this particular case the cost is low, and I don't think that avoiding it would noticably increase throughput on working sites.
The thing to do is to concentrate on more costly queries and avoid them (again, usually by judicious caching). There's a LOT to be gained there, particularly if you're doing queries to summarize recent content, do personalization, manage portals etc on user pages - such SELECTs tend to be fairly complex and therefore expensive.
