If you don't need transactions, why are you bothering with a database? Just use a coherent shared-memory cache and dispense with the slowdown from parsing queries.
It's called a design decision, and the postgres developers decided to focus on features important to people who need transactions. If you really want this 'feature' (non-transactional behavior), and it can't be set as one of the transaction isolation levels, I'm sure they'd be willing to accept a patch from you.
Or use Postgres' autovacuum features. You aren't, by chance, referring to an ancient version of Postgres that lacked autovacuum, are you? I was under the impression (having used Postgres in some fairly heavy-duty deployments with thousands of concurrent users) that this is exactly what VACUUM takes care of. Autovacuum must be even nicer. I wouldn't know, I seem to use MySQL all the time nowadays unless the task requires a real database.
Or, hell, you could (gasp) use MySQL. Its original design was focused on non-transactional database needs. It's great for light-duty things where you want to throw them together and not spend too long optimizing queries.
Use the right tool for the job... maybe postgres isn't the right tool for your jobs.
That's not really something you can attribute to the tool manufacturers, you know?