throw is bad.
EEP 0049 is a whole set of bad ideas.
Deeply nested case is bad.
Using if where it doesn’t belong is bad.
try ... catch is bad, but there are a handful of builtins and library functions that force you to use it instead of providing an ok | error return (use try to wrap those so you can provide a proper return type, and then leave those abominable trys out of your main code).
Worrying about performance before your system even works is bad.
That Erlang allows shadowing in the heads of anonymous functions instead of matching is bad (but at least there is a warning for this — the “pinning operator” suggestion was an effort to double down on the stupidity which was fortunately not pursued in the end).
The main trouble is that people want to be able to write bad code without it looking obviously, painfully bad. Erlang doesn’t have enough syntactic sugar to allow you to pretend that awful code isn’t awful, and this is a feature, not a bug. Don’t try to “fix” that.
The cause of this trouble is probably that most coders out there have not had the good fortune to be allowed (or the personal concern to pursue) deep intimacy with the problems they are solving, so they have deeply nested data types, tons of header files sharing record definitions (or worse, just flub it by pretending that maps are a replacement for records), and other fundamental problems with the shape of the data they are using throughout their programs — and ugly data shapes make for ugly code written around those ugly data shapes.
Fix your crappy data shapes. Refactor your code around better data. The ugliness will straighten out, the code will be dramatically more readable, black magic like list comprehension hacks will evaporate along with abuse of if, throw, and other nonsense, and the resulting assembler will simply be better. It also is much easier to pick names for things when you have your data shaped correctly.
Figuring out the most natural shape for your data is one of the hardest problems in programming, and the aversion to even thinking about this carefully exacerbates the second hardest problem in programming: naming things.
You cannot solve any of this with more syntax. More syntax is bad. The best syntax is no syntax. Erlang already has too much syntax and too many keywords. Don’t make that situation worse.