Yes, that's quite a good piece.

Apart from thinking that people usually don't use the features that make recovery in the presence of multi-database transactions work, his point of view seems to be much the same as mine - there is no problem with transactional consistency until you run into the need for recovery, and then you need to have set things up correctly and have the necessary procedures in place to make recovery possible - it won't be possible if you don't do that. And his remark (for the multi-teneant scenario)

suggests that we are not even too far apart in emphasis. But my previous post probably wasn't suffficiently clear about the need for "code, tools, and rigor". I said "a degree of discipline" when I meant "careful design, choosing the right tools, and having the right procedures in place and ensuring that they are followed rigorously".

But he appears to think that simple recovery model is much more commonly used than I have seen, and that no-one uses the full recovery model and recovery to point in time (or to marked transaction) and as a result of that view he expects the problems of restoring to be generally much nastier than they acually are for people who alreadyuse those features. Even if people don't normally use full recovery, it is possible to switch all the databases from simple recovery model to full recovery model immediately before starting to take any full backups, and after all the full backups have completed take a log backup for each database and then switch back to simple recovery - that allows you to use point in time (or marked transaction) recovery to a point shortly after the last full backup end time without suffering the backup storage (and IO) penalty of running all the time with full recovery model - it gives you equivalent capability to what you would have for a single database using simple recovery model, in return for not much storage and a slightly more complex backup system (which can easily be automated, of course).

Also, he doesn't consider systems which have chunks of time when no user transactions which write to database are allowed - for example systems where a period overnight is reserved for MI queries (which may write reports into a separate database) and for administrative tasks like index rebuilds; doing full (or incremental) backups during such a period ensures transactional consistency on recovery, since the databases concerned are in a static transactionally consistent state while the backups are happening. This works perfectly even with the sort of simple recovery model only system he thinks is far more common than full recovery.

Another point is that transactional consistency is maintained automatically if each transaction updates only one of the several databases. In my experience it is very often possible to split the data in such a way that that is true. He mentions a couple of generic scenarios for that, but there are specific ones that don't fit into either of those generic descriptions (Brent Ozar's comment on the blog mentions two of them; another one is where history deletions in an active database is delayed until confirmation of secure backup of an archive database containing the data is available, which is actually a pretty common technique, often done manually but sometimes automated).