I think technically yes, but as I suggested it’s probably negligible in terms of impact on performance. I guess a much bigger factor would be what you subsequently do with those relations. For example, let’s say you create a relation to a table with 5k rows. And then you add a series of Lookup columns to fetch values via that relation. Then you might use the values from those lookups in a template, and then use that template to create another relation, and so on… All of this is going to create a much bigger computational load, because every calculation has to be done 5000 times.
But honestly, I think we might be making too much of this. The app I referred to earlier in this thread (the one with 30k+ rows) also has roughly 2000 computed columns, and at least 100-200 relations, with many of them being quite complex - lookups and math columns and if-then-else columns and templates - all feeding dynamic relations and constantly changing based on user interaction. And… the app works fine. So, at least in my experience, I think you need to do some pretty crazy stuff before you create any significant negative impact on app performance with computed columns.
Also, we know that in the not too distant future apps will be migrating to the NCM (New Computational Model), which can be expected to provide a bit of a performance boost.
Yeah, but as you noted earlier - relations only provide a pointer and don’t contain any actual data. So there is nothing to copy 
If you had a lookup based on that relation, you could probably make a static copy of that. But all that would give you is exactly that - a static copy of the data, which would be redundant and no longer in sync with the data in the source table.