I have read many perspectives like this of late on this mailing list. In summary I think that Org is such an incredibly flexible and powerful tool that many users have not the faintest idea what other users are doing with it (for example I am completely mystified by the level of activity in the one vs many files thread and its counterpart on the orgmode subreddit). Despite this, in a sense, Org is just as simple as it has always been which is why people build on top of it, and thus there isn't really any way to "go back" to a simpler time -- such a time is fictional, it has never existed. I can say for myself that it is not Org that has changed, it is how I use it. I used to use it in simple ways, and still can if I want, but now I use it as a substrate for self describing (sometimes self-modifying) interactive programs -- as complex as you can get.
For some use cases there are performance issues and for others workflow issues. The performance issues are likely to be resolved via more developer time. The workflow issues have to be resolved by writing custom elisp code, in many times that elisp gets packaged as org extensions. Thus we arrive back at your original complaint, which is that Org files are not sufficiently self-contained. In order to make them self-contained you currently have to copy and paste a bunch of boilerplate into files (thus the workflow issues). For some things the boilerplate is seemingly unavoidable, even using #+setupfile: doesn't work if you are trying to solve a problem in a certain way in Org. Other times, you could solve the same problem without any boilerplate using a slightly different approach, but not always. I have been working on an extension for Org (orgstrap https://github.com/tgbugs/orgstrap) with the goal of making Org files self-describing, if not fully self-contained (There is a distinction between the two, but only for certain failure modes. Also, why force __DATA__ to be embedded with the file when everything has to be dereferenced at some point anyway? You could embed it later if it fits your use case, or you could embed the org file in the data!). I came at the problem from the perspective of reproducible research, but it seems like there are many use cases for being able to move information implicit in the environment into an Org file explicitly. If you want a database to handle relational data, great, describe what you need to access it in the org file that will act as the interface to that relational data, that way if the database access is down you won't get cryptic errors, but a big warning that says "hey! a service required to use functionality in this file correctly is missing!" For the described frustration with needing to track users, give the org-file an embedded id and use that to access and update the assignees associated with a file. There is no need to choose Org or something else, you can have your comfortable org-mode workflow, and your data-appropriate store.