Actually I like the feature and its a nice completion of LC functionality

There are much weirder things hidden in LC semantics with guards vs. other conditions behaving differently as filters

1> [ foo || 1/0].
[]

[ foo || throw(err) ].
** exception throw: err

3> 1/0.
** exception error: bad argument in an arithmetic expression
 in operator ‘/’/2
 called as 1 / 0

so 1/0 behaves like a guard (exception -> false) in LC filters, but other exceptions e.g. a function that throws a exception behaves differently

So if we wrap the 1/0 in a function it behaves differently:

4> F = fun() -> 1/0 end.
#Fun<erl_eval.20.82930912>
5> [ foo || F() ].
** exception error: bad argument in an arithmetic expression
 in operator ‘/’/2
 called as 1 / 0

But the generatorless LC is fine IMHO:

[opt1 || cond_for_opt1() ] ++ [opt2 || cond_for_opt2()] ++ [opt3 || cond_for_opt3()]```