First, it calls unsound the fact that an exception gets thrown in the shown code. There is no data security issue, no possible JVM escape, no type system failure. You can get the same cast exception with straight-forward code. The claim of unsoundness is merely based on the fact that the problem is obfuscated. Using unsound here is misleading.
Second, the whole point relies on implicit type relations that are not checked at compile-time when nullptr is involved. Certainly, it's a weakness in the specification that can cause suprising run-time exceptions, but it's not a hole in the type system.
Third, it makes claim that the JVM was saved by its early choice of backward compatibility. This is a bad habit that I've seen elsewhere: making claim about unspecified, unknown alternate histories. In this case, had generic not erased type, then assignment from nullptr would not work. Surely, the nullptr would have acquired typed alternative (nullptr<T>: nullptr<String>, nullptr<Integer> ...) which would have letthe compiler type-check properly and catch the problem at compile-time.