You are right, stateless is indeed a difficult threshold to cross. But what if the cost of callbacks is far greater than the need for stateless? I mean, when dash is deployed on some metered services.
Or we may not necessarily use delta data. As you mentioned, multiplexing, which happens to be splitting a large callback into several small ones. And the process of splitting may be judged and processed by the program, and then the two ends maintain the same principle. When the serialized data is split into several small pieces, the server can send the hash value before sending the actual data. Then, theoretically, it probably still remain stateless.
Since you know that’s not the right tool for my use case, you still sent it to me, so it’s a compromise for me. 
In fact, when I update the graphs, it comes from the data processed by sklearn, and those inputs are just a series of model parameter adjustments. Whether splitting or locating relevant properties, it may make my code very complex. And I don’t think it should be up to me to do that.
I didn’t say that was a flaw, either. But it does bring in redundant data. So what I’m saying is, don’t mess component designers and users around , but find a way to optimize this problem.
This extendData property might be more suitable for my MQTT example.