readObject is not something on the server, it is just a method signature defined by the serializable interface in the Java standard. The vulnerable code needs to be on the server of course, or there is nothing to abuse. The vulnerable code is in the Apache commons library, which has a class that implements serializable and therefore provides a readObject method, that can be abused.
But then you write something like "Serialized objects in Java is no difference than SOAP requests or JSON objects, or CORBA or other means to do RPC/RMI". But that is completely wrong in this context. The reason we have this bug is exactly because there is a difference from java serialization and all of the others that you mention. And that difference is that the serialization data includes arbitrary class names that allows the attacker to cause your code to load _any_ class that implements the serializable interface, no matter if that has anything to do with what you are working with here or not.
If you use JSON you will not have that. JSON can only cause strings, numbers, arrays and hashmaps to load.
This is also wrong: "Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!" - yes the exploit is in a readObject implementation, but that exploit allows the attacker to transmit arbitrary code and have it executed. Code that was in no way on the server already.
"First of all: there is no outside code executed when you transfer an object, the article is wrong with that. So you need a way to execute your code. The only way I can imagine is" - or the way the article describes. Which is not a derived object. He sends a serialization of a completely different object, namely the vulnerable class in Apache commons. The deserialization in Java just returns "Object" - there is no expectation here that the returned object be of the type that you, the programmer, expects. You will then of course get a class cast exception if you just cast it, or your code will notice something is not right if you do a isInstanceOf on it. But by then it is too late, he already had his custom code executed by Apache commons when the readObject method in there was called.
You need to know absolutely nothing about the system you want to attack. You only need two things, one is for the system to be vulnerable (=Apache commons needs to be on the classpath) and the other is that you need to find something the system serializes. You do not need to care about what it is that it serializes, because you will provide it with your hacked object, and the deserialization will fail but by then you already got what you want.
So if your web application does not use serialization the second prerequisite will fail and you are safe. But if you did something like putting a serialized object into a cookie, then you are done for.