"I am pretty sure you will get in trouble."
This. While it may not cause cluster partition (this would only occur on leave/rejoin attempt) the performance could plummet and VMs wouldn't like that.
"Well, I've changed vDS MTU to 9000 already. Nothing major happened during that change."
Yes, that is completely expected as it is still operating at 1500 MTU as the vmk is the end-point and thus dictates the packet size (though yes of course it does need to be configured correctly at 9000 at everything in between the vmks on each node).
"just creating a new interface with a different MTU. So there will be again the same moment when I will swap 5 hosts to new vmk while another half will still remain on old MTU."
I think was maybe thinking what I was going to suggest:
1. Add new vsan-tagged vmk to all nodes in the cluster in new subnet and with 9000 MTU - it *shouldn't* switch over to these automatically e.g. it will still use the original ones.
2. Place a node in Maintenance Mode and then untag vsan-traffic on the original vmk, validate that the node doesn't become partitioned from the cluster (e.g. using the new vmk to communicate with nodes).
3. Proceed with this until all nodes are just using the new vmks and remove the old ones.
That being said, network changes are not something that should be done on the fly, just because something is technically feasible doesn't make it a good idea, if you can get a short downtime or quiet time of day/week to do this then do that - there is just too much scope for error and/or after-the-fact realisations of things that were missed or incorrect assumptions about the configuration, trust this coming from someone that helps clean up the aftermath of such changes more frequently than would be preferable.