I guess, this technique does not apply to legacy codebases or to codebases with code coverage not in the 90%s or codebases with some amount of tech debt already introduced or "ball of mud" codebases?

The TBD style requires good discipline in any non-trivial codebases, and all the developers being experienced and accurate with this "eventual code review" way.

I'd say feature branches are much better at capturing logically complete changes. They also enable developers to return and see what every feature required, including the design decisions made for the entire feature, not just parts of it. It is simpler to trace things from requirements to pull requests, etc. It is also easier to measure progress, as it is captured in the feature branches and sub-branches. Additionally, TBD is not a prerequisite for successful CI/CD.

Code reviews not blocking? So, basically, some unchecked code goes to production and, in a few days, can ruin the production database, requiring efforts to fix it and apologize to clients? And do not tell me unit etc tests are going to prevent this. Some problems like understanding requirements will still slip. Two heads are better than one. Pair programming? This might waste a lot of time if used all the time instead of more focused use on really challenging problems.

The article failed to convince me the technique described will really improve software quality. Maybe, under some rare circumstances only.