My biggest issue with this notation is that the following is valid on its own:
{ // code ... }
Nice argument, but such blocks are not supported in Kotlin I believe.
Other than that, I agree that the Kotlin devs / community seems to be pretty settled with the “open brace at the end of a line” syntax, because that is also how the short lambda argument syntax works.
Very good point, I guess that was my problem in the Java world, but it solved itself in Kotlin 
I updated my post.
Actually they are allowed, but not generally useful on their own. That would basically be declaring a lambda but it would be unused unless based on position it happened to be the return value for a block. But if it is unused IntelliJ grays it out to tell you.
Is this what we want to emphasize, though?
IMHO, the point of using if guards at the beginning of a function is to rule out special cases, that should be unimportant at first to the reader. The reader can skim through the if-starting lines, and stay at the 0-indent level to see the general case.
That being said, I have never been exposed to this return X if Y style, so maybe that’s just a question of habits.
However, I have to argue in favor of keeping as few language constructs as possible to keep it easy to learn. I can do this with if (condition) return X, which is to-the-point enough to not require an additional construct.
The point of coding style guidelines is to define rules which when followed consistently allow the clearest communication of the intent. You cannot say this style is bad because someone could violate the rules in other ways and the intent would not be clear. That violates several other coding styles. First off my personal style (as I mentioned before) is that any instruction that produces a non-linear flow, such as a return statement must be on its own line and separated from other code by a blank (or brace) line. So return should be on its own line, it should be separated from the if by a blankish line and the if should be separated from the block by a blank line because it is not part of the if.
I fail to see a difference from just an if.
Problem here is that you are doing 2 things in one line. And in this case mapTo represents a non-linear flow. I would write that as:
listOf(1, 2, 3)
.mapTo(ArrayList())
{
2 * it
}
or in this case since the lambda is so simple probably:
listOf(1, 2, 3)
.mapTo(ArrayList()) { it * 2 }
People disrespecting style happen, and one way of evaluating a coding style could also be how resistant it is to violations of its invariants.
That being said, it’s a very weak argument if we consider that we can enforce coding style at build time somehow, so I totally agree with you on this.
That’s the point. Consistency between ifs and functions “applied” to blocks (technically taking lambdas as arguments). Which brings us to my last point, which was that consistency can also technically be achieved if we wrap the opening brace both on ifs and on lambdas passed to functions.
Given your examples, I’m under the impression that this is exactly what you do.
Even if we ignore the fact that most Kotlin docs and examples out there don’t follow this style, there is also the DSL world to consider and they don’t seem to follow this syntax either (e.g. Gradle files). I’d say I’d rather go with the flow and follow the trend to achieve cross-project consistency rather than personal preference (but that’s a bit too easy since the world aligns with my personal preference in this case).
That is exactly what I do unless the lambda is all in one line with the function. In fact, you can thank me for that even being possible in some cases without the inspection complaining. See my bug report that changed this behavior. It means sometimes adding an empty set of parentheses but I can accept that compromise.
I’m a fan of Allman style (though I accept that in my workplace K&R has won), but this feels wrong. mapTo() is a function that takes two arguments, a list and a lambda. Both arguments should be on the same line.
Which I guess is an argument in favor of K&R, if only for consistency.
As I said in this case I would do it all in one line, but sometimes the lambda is longer and is either too long to fit on one line or actually includes more than one line in which case Allman is the way to go.