1. RFG vs child posts
They are so similar under the hood that it really is very much a personal preference.
Right now the UI for adding RFGs in the backend is pretty nice, but on the front end you have to use the equivalent of CRED child post forms for each group of repeatable fields, so there is not much to choose on that basis.
If you are likely to be creating related posts/RFGs programmatically, well, the relationships API documentation makes no mention of adding RFGs using the API.
2. I think there will be less overhead using Views Content Templates on their own rather than any other solution which combines some templating solution with inserting Toolset content (Types fields, Views, nested templates etc.).
The only real way to quantify this would be to use the Query Monitor plugin and try it on a version of the site that is built with a page builder + Toolset, versus a version of the site that is built just with Views Content Templates.
3. I think I understand. Imagine your starting point, and your destination, and what's involved getting there.
So if you are on a post and you want to display a field which is added to a taxonomy term which is assigned to the post, then you would you can display the field with the wpv-taxonomy-field shortcode, but the context for that is a taxonomy View, so you need to create a taxonomy View with a filter to return the right term for that post and output the term field and insert the View into the template for the post.
That's more overhead than simply storing a field directly on a post and retrieving the post meta for that post.
But if it doesn't make sense to store a custom field on the post, what's the alternative? Related posts? Then that is no better than the taxonomy solution.
4. Your templates are pretty complex and pull in quite a bit of info using different queries. The only thing that occurs to me is to try and avoid duplication of queries.
So if you have one query near the top of the page and the same query lower down the page, try to re-think the layout of the page so that you can use the query only once.
An example would be if you have nested Views, and you use the same "parent" query to create the context needed for a "child" query in more than one place, maybe they could be combined.
I don't know that you are actually doing that, it is just what comes to mind when you have so many queries and embedded templates within the same page, look for ways to avoid duplication.