This would be for deploying a database migration that hoses something. For instance, we had a migration that touched a bunch of tables and, due to a triggered procedure, it blew away all the modification dates.

TBH, I'm not sure how useful it is compared to the normal PITR. My usual guidance on recovering after a database fuck up is "put the app into maintenance mode and the database in read-only, do your investigation, run PITR, port user activity to the backup, do spot checks to determine everything got through, roll the app back to before the change, take the old database down, point the app at the new database, bring the system back online."

I'm sure a manager is thinking, "oh, we can be back online in 5 minutes, amazing!" But just because something broke doesn't mean users stopped hitting your database! You can't just hit Undo and throw all that out!

Because nearly everyone I know has some memory where at a less experienced point in their engineering career they wrote:

delete from ImportantTable where id = 1234

... and forgot to select the second line in some query editor before running.

First, Transaction is not free, there is overhead comes with it. Second, it could be upstream software bug, that writes wrong data to the DB, you can possibly overwrite that.

That's for the cases where you only realize the mistake after the commit. Often because other queries suddenly fail.