Tldr: Clear distinction between vulnerabitily classes ist not always possible.

To look at "insecure serialization" in a different way first:
From the description, Owasps "insecure serialization" is a bit of a foggy mix of (imo) 3 separate problems:

• A specific subsection of plain untrusted input values for the very first - who cares about serialization formats. In your code block, the admin:true (and the server believing this value) is the problem, nothing else. If it stands alone, outside of any Json etc., it's still the same problem.
• Still untrusted input, but another section: Exchanging code (classes, methods...). If there is some dependency injection going on for a EncryptionAlgorithmInterface, and the available implementations are None, DES, AES256 and so on - what could I do with the serialized object? Changing the algorithm to none and then find a place where I can read the data while send over the internet.
• Problems by definition in the serializer itself. What if send a never-ending stream of [[[[[[[[[[[[[[[... to a web service expecting Json (ie. Array of array of array of... and the values and closing ] are never sent)? A simple implementation will quickly reach a stack overflow (error, not website), crashing the server process.

Your Json web token link...

• is at least untrusted input.
• It also is (Owasps) insecure serialization, but really, who cares - the problem again is not the data format.
• After the explanation was written, it also became "running components with known vulnerabilities".
• Not in Owasps Top10, but it is also a protocol definition problem.
• ...

Finally, about the part of native serialization that offers more than Json etc.: Well, partially - but this doesn't make eg. PHPs version secure.

In Java it is possible to take an object, write it's complete state to an byte array (that is, current member variable content (both simple types as well as other objects), but also executable binary code in some situations, etc.) and then recreate everything from this byte array. Access to a serialized Java method that will be executed later is of course very nice for doing bad things. And if there is none, introducing one that will be called because of its name at some point (eg. equals) is easy too.

In PHP, there is not such a straightforward way to save and load executable code parts like the runtime has them in memory, so abusing this is not possible. However, names of other methods to call might still be in there. That's not as convenient, but still nice.