I partly agree with your statements.

The readability example certainly makes the point that Kotlin offers more temptations to write hard to read code compared to e.g. Java. The other examples don't make that point IMO.

The productivity example tries to show how the interoperability between Java and Kotlin leads to bad code. As I pointed out in my response, interoperability can be seamless and doesn't offer any language specific "temptations" to write bad code.

The maintainability example just shows bad code because someone wrote bad code. There's nothing language specific that makes this code bad. Similar bad code could have been written in Java too.

So as far as the article is concerned, parts of it make the point you mention (that it's too easy to write bad code in Kotlin).

Now to the statement itself (it's too easy to write bad code in Kotlin). Whether a language offers too much flexibility or not is a very "personal" assessment. Some companies have the processes in place to reign in excessive use of that flexibility, other companies don't. It also depends on what the company is trying to build and at what stage the company is. For some use cases Java is way to flexible and a more strict language (like ADA) is appropriate. For other use cases Java is too structured/static and more "dynamic" languages like JavaScript or Python are better suited. Kotlin does make it easier to write hard to read code than Java but its advantages outweigh this one disadvantage by far (just my personal opinion).