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).