|laziness, impatience, and hubris
How do you maintain transactional integrity in a situation where Perl objects reference multiple tables and different Perl objects might have overlapping table references? It seems to me that sometimes, you want to make sure that a number of Objects being updated result in the database tables being updated atomically and not understanding the impact on the underlying tables might lead one to believe this is being done when it's not.Then your encapsulation/abstraction is broke^Wsub optimal.
Your example seems to come from a notion that still has a very tight coupling between data layout and Perl data structures.
Conversely, you might only want to operate on a single object and have that update the table without waiting on operations on associated objects."The table"? What table? Again, loosen the idea there should be a mapping between tables and objects (although you probably mean rows and objects (or tables and classes)).