I get where you're coming from, but it'll be hard to get help from the compiler on this. Not every copy is unnecessary nor a performance problem, and the compiler doesn't really have great insight into which cases will be acceptable and which won't (though maybe when PGO is in use, it could).
It'll probably be more viable - and to the point of what you care about, performance - to focus on profiling and benchmark unit tests. That way you can ignore any copies that don't actually matter, and you'll also catch performance problems due to more than just copies. You can make performance testing part of your development process - e.g. part of your CI pipeline - and even block integration of patches that introduce regressions.
I don't think that's accurate (nor a desirable constraint). Swift is a pretty high-level language that nonetheless aspires to be very performant, and that means it has to do some pretty advanced optimisations, such as eliminating entire instantiations of structs let-alone mere copies (e.g. to make lazy Collections and Sequences fast, you can't actually allocate all the intermediary structures nor actually have them chain calls through each other for every element you fetch - it all gets completely eliminated by the optimiser until you're left with a trivial loop and the essential operations, potentially just a few machine instructions).
It's true, non-copyable structs currently don't play well with those features. There's work underway to rectify that, although it's probably still some way off from landing in a Swift release.