The weak-strong dance is probably one of the most annoying aspects of Swift — but it has always been that way, and I doubt that after all those years someone will come up with a "solution".
Possible options
Breaking compatibility isn't a real option anymore, so there is a quite narrow corridor when you don't want to accept other compromises.
Inferring weak automatically when the body of the closure indicates that (self?.doSomething(), guard let self = self…) could be an option, but I wouldn't push toward that direction (too much magic); a second way to specify closures (without deprecating the current one) wouldn't be perfect either…
At least partially, it's not even a problem of how closures are used, but rather where:
People tend to hype and overuse "new" features, and I see blocks in that phase — which is usually followed by a backswing, so I wouldn't be surprised if future developers look at closures, async & await or protocols in the same way as some coders look at subclassing or global variables now (and they'll be as wrong as the extremists today).
Take Network as an example, and search for the words "A handler that" in the documentation of basic types (NWListener, NWConnection).
All those handlers create a high risk for retain cycles, and can't I see any real advantage of this design. Some years ago, it might have been implemented as a delegate, and I'll go even one step further and say that subclassing would actually be the best choice: It is simple (only one object), and there is little danger to use it wrong.
There are places to use "modern" features like closures, but I neither believe in silver bullets, nor do I follow dogmas like "never use inheritance".
Bottom line: Choose your tools wisely, and when closures cause problems, there might be alternatives which actually perform better (of course, this advice doesn't help with existing API 
).