It will probably not be easy to create a test setup for this, and then measure and compare the "performance" to a setup that does not use VLANs on vSwitches. (Although I have an ESXi server for testing, I don't have spare SQL server VMs at hand). However, there are a few sources that can give us clues.
When looking at the diagram (in the article you are referring to), notice that there are 3 (virtual) vSwitches, connected to the VMs via red/yellow/blue arrows. Also notice that there are only BLUE arrows leading away from the PHYSICAL ports, leading to a physical switch (hardware).
Now - due to the facts that (as your network admins wrote in their email) "Broadcast traffic would be confined to the VLAN." and "the vmnic does not have a hardware speed limit" i.e. the performance in the "Availability" and "Backups" VLANs are is NOT determined/slowed down by the physical switch, and: Broadcast traffic from the other nodes on the LAN would not hit the "Availability" and "Backup" VLANs. Quote from https://communities.vmware.com/docs/DOC-25426 (emphasis mine)
VM1 and VM2 are connected to same vSwitch called "vSwitch1" ,same port
group called Production and also same VLAN called VLAN 20 and also
both are running in the same ESXi host called ESX1. Network traffic
between these VM's (VM1 & VM2) does not go to physical NICs on the
ESXi host and this frames also not forwarded to physical network like
physical switch and router because VM's will communicate within the
vSwitch and results in achieving the increased network speed and
lesser network latency.
Is this really necessary? Some people will tell you that it isn't (because the network is fast enough as it is yada yada). Other voices, however, recommend the "VLAN approach". Why? e.g.
... the availability group messaging throughput requirements can be
non-trivial and can have an impact on the heartbeat and intra-cluster
communication. As a reminder, heartbeat communication is generally
sensitive to latency and if they are delayed by a statured NIC, it
could cause the cluster node to be removed from the cluster membership
link (the word "statured" should probably be "saturated")
or (not directly related to SQL server)
" To provide the most consistent performance and functionality, and to
improve network security, we recommend that you isolate the different
types of network traffic. "