I always wonder about patterns like this, and how they arise. For the kind of Rust code I personally write, I can count on one hand the number of times I needed to deal with a non-lexical lifetime. But it's clearly a pain point for a lot of people, so I wonder where the difference is.
Fixing a compiler error by adding a lexical scope level has never occurred in any other language I can think of.
This was shocking to me when I bumped into it.
The problem is that you don't have the tools to even ask the right question to debug Rust code when you start. You have to ask questions on the IRC channel or you will get nowhere for quite a while.
A lot of people who program quite successfully in C or C++ do not really understand the idea of scope (which is what lets so many bugs creep in). Rust smacks you with "lifetime" in the face and makes you deal with it at compile time.
For those of us who are in environments where we have to struggle to debug C, the issues Rust is flagging are simply syntax errors. For other folks, they generally have to upgrade their mental models.
"Oh, that would have escaped the function after having gotten freed. Oops." is easy to understand when you have had to debug that dozens of times in C (generally because you accidentally added a code branch that didn't handle something). That error is not so apparent when you are used to simply returning an object in a garbage-collected language and letting the VM handle the issue.
I run into it infrequently (in particular, kibwen's example), but it's like a mosquito bite. "Oh, yeah, that sucks. Ah well, it's not going to stop me from doing what I was going to do anyway." It's definitely a little weird to hear it's preventing someone from using the language, so I too would like to hear more.
I bet it's to some extent an emotional thing, if you're an experienced C++ programmer. "Argh, yet again the stupid borrow checker is complaining about something I wrote that would have would work fine in C++ [which I'm used to]! Now I have to rewrite it for no reason." It feels suffocating. Most of the time, it's because the code pattern you tried to use is safe but fundamentally not expressible in Rust's type system (often due to simultaneous mutability), and you need to switch to a different one - which is annoying, but gets less common as you get more Rust experience, and hey, even if the borrow checker feels limiting, it's the state of the art: nobody has done better, you're living in the future. Occasionally it's because your code is actually wrong and would crash in C++, and that really makes you appreciate Rust. But sometimes, quite often in fact, it's something entirely local to one block of code that the stupid thing should be able to determine is safe, but can't, because it's stupid. And that's when you flip the table. That's when you question your decision to use Rust. It's like dealing with buggy software: far more annoying if the thing you're trying to do is supposed to work but broken, than if it just isn't supported. It's not the future, just a profusely bleeding edge.
Non-lexical lifetimes solve only a subset of that last category, but a significant subset.
I can imagine it's preventing someone from getting _into_ the language in the sense that if you run into such a situation, you don't have the mental tools to solve it, and it won't feel just a mosquito bite but worse. Even if you manage to solve it, there's the nagging feeling that there might be more annoying hurdles to overcome – but you don't know yet, so you are prone to give it up and use your time for something else.
It's probably because you're used to Rust and know how to write Rust in a way that just avoids all compiler errors. People new to the language try to write Rust code as if it were C++ or something (or, in general, are not yet used to the Rust way of doing things). I have had this issue with every language I've learned so far, most recently Go (which I tried writing as if it were Rust).
So often newcomers end up designing code in a way that at a higher level isn't too flexible when it comes to borrow check, leading to these issues.
