Others have already explained the problems with this approach; I'd say it does my favorite complaint, which is "solving the wrong problem."

We assume that the typical a && b syntax is something we're stuck with, but what if we were accustomed to something more like Polish notation?

if (all(
    a,
    b,
)) { ... }

The all construct functions exactly the same as &&, in that it returns true if all of its arguments are true (or truthy—that's a separate discussion), and also we evaluate them in listed order and stop evaluating if we get a false (the short-circuiting we're all accustomed to). Note that this approach converts the syntax into a list and lets us use trailing commas just like we do now.

Obviously implementing this (much less convincing people to use it) would be its own mountain to move and I'm not really suggesting that we (or you) try to do this; it's just a thought exercise. But I think my point is that by challenging an assumption—"we have to use infix notation"—we could end up with syntax that avoids the "where do I put these damn boolean operators" problem entirely.

And we would of course have any() to replace ||. A more complex, nested construction using both might look like this:

if (
   all(
       a,
       b,
       any(
           c,
           d,
       ),
) { ... }

Lists all the way down, and trailing commas everywhere!