@Filipe_Cunha I do understand where you are coming from and this is what largely separates a headless CMS from an API framework. We have to take design decisions that related to the software functioning on a headless CMS level with features needed by some but not all and this requires us to build things that are able to cover both of those use-cases.
To have an option to disable those join tables on project creation would result in a very manual and risky migration process should you ever want to enable them. Likewise giving the option to disable them. Our solution was to enforce their usage for everyone to make future feature development easier on us (less tests needed to cover multiple use cases) because we can predict the state that a users application will be in.
This is exactly the same reason we dropped support for MongoDB because there were two major states a users database could be in and we had to account for both as we developed features which lead to a lot of frustration when something would work on database type A but not type B.
We certainly do try to give as much freedom to the end user by default but in some cases we do have to make choices that generalize Strapi’s usage and not specialize in one particular use-case, as you can image there are practically an unlimited number of use-cases; to the point where you need to build software that works on all of them (or least say 80% of them) is impossible without saying “yeah your use-case may not work with us unless you do what we are doing” and this is both normal and expected.