There is strict reasoning why ternary expressions are, in fact, logically better than a typical if statement.

The reasoning is because ternary operations eliminate programming singularities.

Example:

   var x;
   if (someExpression) {
       x = True;
   }
   //var x is undefined

Example 2:

   var x;
   x = someExpression ? true : false;
   // use of ternary expression prevents var x from ever being undefined.

The ternary expression forces you to handle the alternative case while the if expression can leave a singularity. A hole where x remains undefined.

Some people say ternary expressions are less readable. But Readability depends on your "opinion." There are no hard logical facts about this. So it's a weak-ish argument.

It is actual fact (ie not an opinion) that ternary expressions are categorically more Safe then if-statements. Therefore, they are factually better in terms of hard logical metrics.

This is the reasoning behind nested ternary statements. It's also one of the strange cases in programming where superficial qualitative attributes of "readability" trumps hard and logical benefits. The overwhelming majority of the population will in fact find many nested ternary operations highly unreadable and this "opinion" overrides the logical benefit.

Usually though, to maintain safety and readability I just alias boolean statements with variable names. The complexity of a conditional expression can be reduced by modularizing parts of it under a symbolic name, you don't necessarily have to reduce complexity by forcing the conditional into the more readable bracketed spatial structures favored by if-statements.

Example:

   isXgreaterThanY = x > y;
   isWlessThan2 = w < 2;
   isSubExpressionTrue = isXgreaterThanY & isWlessThan2 ? False : True;
   isFactNotTrue = isSubExpressionTrue ? False : True;

Yes technically the ternary expressions are still nested in a way here, but when reading this code you don't have to dive in deep past the symbolic name.

Imagine if you have a boolean condition that relies on multitudes of these sub expressions. By defining the final statement as a composition of Named ternary expressions you eliminate the possibility of a hole;... a singularity where one alternative wasn't considered. In my opinion this is the best way to define your logic.

If-statements, imo, should be reserved for functions that are impure (void return type).. code that mutates things and touches IO which is something you as a programmer should keep as minimal and segregated away from the rest of your pure logic as possible.

Example:

     if true:
        sendDataToIO(data)

     //the alternative of not sending data to IO is not a singularity. It is also required... a ternary expression makes less sense here.

Last but not least: The ternary expression is also a bit weak because it only deals with two possible branches: True/False. The safest and most readable primitive to deal with multiple branches of logic is exhaustive pattern matching. Both Rust and Haskell have a form of this. In rust, it is the match keyword.