I'm not sure how "tongue in cheek" this article was supposed to be, but most of his issues with the problem can be solved by buying into the language.

For:

Not sure what he's upset about, but there are many options in the standard library. I almost never use the language construct for it, and I'm very happy with it.

Nullable:

I never expected nullable to completely save me from all issues. It has the same function as the @Nullable and @NotNull annotations (and all the other variants). It gives you a simpler way to reason about nullability, and forces you to respond to it; you can't just ignore it.

Smart cast on mutable

I get that this sucks, but they can't show it to happen. Yes, the chances are small, but there could be concurrency issues. They have to account for that, and can't tell if your code is multi threaded or not.

Most of the time his issue can be solved with scoping, using ?.let or ?.apply

Java Nullability

What do you want from them? They have no ability whatsoever to control this. Either get annotations in the Java code if you can modify it (which is a good idea anyways), or wrap it and provide nullability information.

Assignment is not an expression

He got it. It's too protect against if(v=v). I know he makes a joke about automatic type casting, but if you're not assigning the result to anything, the logic in the if will still fail.

Elvis operator

I assume they removed Javas ternary operator to not get confused with the Elvis operator. ¯\_(ツ)_/¯ I kind of agree with him here unless I'm missing something

Automatic type casting

Frustrating, but safe

Type alias

I'm fine with it for simple cases, didn't want to parse his problem.

Generics

I hear his gripe, but at the end of the day Kotlin generics are Java generics. If there are some potential bugs in the compiler, report them and move on.

Structure syntax

I assume he means list and map literals. I agree it would be nice. Not sure why they didn't include it.