Unfortunately not, in order to build a specific set of features in the future (mainly content versioning) we needed to add that central table to help handle a primary use-case which is versioning of relations.
In the future we want users to be able to have a published version of an entity but also be able to work on at least 1 draft and then through the process of things like review workflows and publication automations be able to release that draft into the published state but also be able to rollback if needed.
As you can imagine normally in a oneToMany (or any relation really that would normally just rely on the 2 tables) this makes it impossible to have as it would effectively become a manyToMany relation. That central table will be used as a means to build that manyToMany but keep the logic as a oneToMany.
We introduced this for all content-types in v4 as a means to build the foundations of the features we want to build but we wanted to prevent the sins of our past by helping to prevent future breaking changes that would require another complex migration in the future. Obviously we can predict all future outcomes but we are certainly trying our best.
If you don’t mind me asking, what are you attempting to do in your RAW queries as there might be a better/easier way for you?