I can agree with you that there shouldn't be a need for nested
transactions, but sometimes, one developer might be working on a
component, and another developer would be working on an interrelating
component. As you can see there might be times when nested transactions
might be something that could have some validity.

In some stored procedures for example, you might want to have a
transaction, and this transaction could called from an application that
might have a transaction frame. In some other implementations of SQL,
I have seen this used, where the innermost transaction is not committed
until the outer transaction commits.

Of course this is just my opinion, but even if coding nested
transactions is "bad" practice, some people coming from other SQL DBMS's
might wonder why there is a "problem" with nesting transactions in what
is supposed to be an enterprise class DBMS.

Personally, I don't rely on the DBMS to handle my transactions for me,
while it might be easier, I deal with real time databases involving
transactions over time a time period where multiple clients access the
same data set, so I handle the rollbacks myself primarily, to minimize
the potential for deadlocks.