Bravo!
Thanks for writing this up.
For me transactions is a core functionality that simply must be there from day 1 if the software deals with databases.
Low-level transactions as they been suggested (i think I saw some support for it have been added to the database package in the latest release) are not the solution, unfortunately.
It is bad approach from software design perspective and is almost guaranteed to bite you later when Strapi change layout of stored data.
Not to mention that writing those knex transactions when you update something with relations and components is a fiddly process.
You are spot on when you say that because it is not documented it is quite a surprise for those who discover it: For a year I was building something based on Strapi v3 (with transactions) then I hear that I MUST migrate to v4 and V3 will go down eventually. I feel irritated but this is not a deal breaker. But then I learn that v4 does not have transactions! Yet I am forced to adopt it despite the fact that I NEED transactions. And what do I do with a year of development with Strapi? I really went through all the 5 phases of acceptance with Strapi through this experience 
Eventually I modified and patched one of the PRs with high level transactions to my code base. But instantly found that it is very dangerous when lifecycle hooks are used (causes locks, etc).
So I still use it but I am aware of issues and have to work around the poor design of the Database package for now.
I strongly believe that Strapi team should re-consider this as an absolute high priority and work on high-level transactions as soon as they can.
Before jumping on shiny features that bring commercial success, fundamentals should be done right.