The choice between lambda and functor-class is a tradeoff.
The gain from lambda is mostly syntactic, by minimizing the amount of boilerplate and allowing conceptually-related code to be written inline, inside the function that is going to utilize it (immediately or later).
Performance-wise, this is no worse than a functor class, which is a C++ struct or class that contains a single "method". In fact, compilers treat lambda no differently than a compiler-generated functor class behind the scene.
// define the functor method somewhere
int operator() (int x) const
if (x == 2) return 5;
if (x == 3) return 6;
// make a call
int outputValue = an_instance_of_0123456789(inputValue);
In your code example, performance-wise it is no different from a function call, because that functor class happen to have no state (because it has an empty capture clause), thus requiring no allocation, constructor nor destruction.
int some_computer_generated_gibberish_0123456789_method_more_gibberish(int x)
if (...) return ...;
Debugging any non-trivial C++ code using a disassembler has always been a difficult task. This is true with or without using lambda. This is caused by the sophisticated code optimization by C++ compiler that resulted in reordering, interleaving and dead code elimination.
The name-mangling aspect is somewhat unpalatable, and debugger support for lambda is still in its infancy. It can only be hoped that debugger support will improve over time.
Currently, the best way to debug lambda code is to use a debugger that supports setting breakpoints at the source code level, i.e. by specifying the source file name and the line number.