That's just a ternary operator. I use that in Java all the time.
value = boolean ? this_value : other_value;
And in Javascript, once do-expressions go from a proposal to a common part of the language, this will be a thing:
let value = do {if (boolean) { this_value } else { other_value }}
What's the advantage over JS's ternary operator?
I guess it depends on whether "if" is treated as an expression which returns a value, which I don't think is the case due to the fact that I don't think there is an implicit value return in JS (such as in Ruby; the final line in any scope is the value that scope returns; same as in Elixir)
(This example comes from Elixir.)
value = if boolean, do: this_value, else: other_value
is undefined in some circumstances unless an "else" is included.
This pattern might seem weird to OOP folks (the assignment, not the ternary-operator-style logic), but in Elixir-land, it is not only considered superior to assigning inside if/then logic, you actually get a compiler warning if you assign/bind to a variable inside a logical expression because (again) that value becomes undefined as soon as you leave local scope (or re-acquires the value it had in the outer scope, thanks to immutability).
And if you think about it, values can only travel in one direction using this scheme, which further simplifies reasoning about information flows.
I would argue that this is also superior to early-exit as having one entry point and one exit point is much easier to reason about, and because the extra logical complexity you're ostensibly trying to avoid writing by early-exiting is actually still there, it's just obfuscated... and that complexity should be made obvious (in which case, if it's extensive, it would be a code smell... consider the example of a function with 25 early exits that "looks flat" visually, but which actually has 25 different branches)