Just to be pedantic, you can delegate on implementations rather than interfaces, right? Just delegate to a struct (which also have methods).
I had some trouble getting used to the borrow checker too. But seeing it is the one big thing people warn about with Rust, it went faster than I thought.
I struggled more with things like object safety and with orphan rules. For some reason they're hard for me to get used to - it just doesn't come up in Java or Python...
The Rust documentation and tools are pure gold.
That doesn't include the IDE support as a tool though :-) I'd be a lot more productive if Rust had the IDE support that Java has. (I use CLion which has okay Rust support, but it's going to take time catching up with the long-established languages).
I also have the problem of wanting to write Rust-style code in other languages.
I didn't like it before either, but now I've really developed an aversion to Java objects being references from multiple places. If there'd just be one owner like in Rust then I could assume the object isn't changed.
Smart people had said before that mutable state is hard to reason about, and I believed it. But I only really understood the benefit when the compiler enforced it.
At first the borrow checker seemed like bookkeeping to prevent GC. But that seriously| underestimates it (and your article rightly mentioned threading protection prominently).
But the problem with threading is that your state is changed between lines. That problem still happens to some extent in a huge single-threaded codebase. Sure I set an object field here, and then use it later, but I'd have to understand all the lines in between, recursively, to know my state didn't change.