I see what you mean. I should have clarified that when I'm talking about computed properties producing a novel value, I'm talking about large values that are hard to copy.
In your example, for instance, I don't see a reason why the borrow getter would need to have a different ABI from the current “consume” getter. A Double is a single-word on 64-bit platforms and trivially copyable, so we should even be able to pass it directly through a register.
I also want to emphasize that my main concern isn't performance, it's fragmentation. Even if an additional copy is generated and the optimizer can't eliminate it, Swift is really good at handling that. In most cases, we'll copy a couple of words or issue some atomic increments and decrements; this cost is largely inconsequential. However, one of Swift's core strengths is that anyone can go to the docs, inspect the definition of a method, property, or subscript, and actually make sense of it.
By introducing distinct syntax for non-Copyable types, we fragment the Swift code into projects that care about non-Copyable types, and into apps that never need to touch them. The Standard Library will inevitably support non-Copyable types in more places, including Sequences and Collections. Given the ubiquity of Collections, it's easy to imagine a scenario where a beginner simply wants to see what a subscript returns, so they hover over the square brackets in their IDE and see a foreign-looking borrow. Of course, borrow is not a hard concept to grasp, but it clearly violates the principle of progressive disclosure. A beginner wants to simply learn about array indexing, yet they suddenly also need to learn about borrow vs get and Copyable vs ~Copyable.