If they just did what was most convenient to implement in Python, that can easily have a huge negative impact: a good protocol has to take into account all the complexity, not just the ease of picking up whatever is on Python's very comprehensive standard library.
For instance, would you serialise your messages in JSON? It sure is convenient. Works with many languages. You can send out text streams, or even binary streams if you encode them in base64. Though it takes some space, so you might want to compress the whole thing before you send it. Possibly over an HTTP tunnel, there are lots of HTTP client & server implementations out there. And all of a sudden you are depending on JSON, gzip, and some http stack. Which is crazy.
If you start from the wire format, and make sure it is as simple as possible, you will get simplicity for most implementations, without dragging it huge dependencies just because it was convenient, you will get performance because you're not wasting your time juggling between formats and compression and whatnot, and you will get security because your stack just got much smaller.
What I fear about IpV8 is that it appears to be Python only. Which is a strong clue that this protocol wasn't designed, but grown on top of what Python provides. At the very least, we need a C implementation with no third party dependency to measure the true complexity of the protocol, and maybe simplify whatever needs to be simplified. I know, C is a underpowered, unsafe language. That's kind of the point: if the C implementation itself is simple, then we know this protocol can be implemented in anything.