I would have to say that yes, you are probably making it a little too simple.
Since you didn't really provide any details of the VMs you were testing against it's pretty much impossible to know for sure, however, my guess is that your VMs are generally small, and that your testing involved running a limited number of jobs at a time, with minimal restore points. Backing up a 2TB VM using 256KB blocks would naturally have a much larger impact than a 100GB VM as the 100GB VM would potentially need 400,000 hashes, while the 2TB VM would need 8 million. On the other hand, a 2TB VM with 1MB blocks would only need 2 million. All those hashes have to be stored in memory, and compared against as the job runs to determine deplicate blocks. As the VM size gets bigger and bigger, the more impact the smaller block size will have. Imagine the impact of 32K blocks on the 2TB VM? Suddenly it would potentially need 64 million hashes, which would certainly be impactful.
You then also need a storage technology that can store all those small blocks efficiently, track the blocks across incrementals and reverse incrementals, and do so efficiently for things like file level recoveries, instant restores, surebackup, etc. The smaller the block size the more likely that the file will become fragmented over time, thus adding another factor to performance.
That being said, if your VMs are fairly small, using WAN mode generally will not have a significant negative impact on performance, at least for backup, but it is a balancing act that has many more variables that your simple test addresses, specifically around restore times and capabilities. Even expensive hardware dedupe appliances have a very negative impact on features like Instant Restore and Surebackup due to the overhead of rehydrating data from their small block dedupe.
In other words, it's not just about about reducing the block size, but about doing so without impacting backup performance, restore performance, and scalability. Right now, 256K seems to be the lower bound that makes sense when balancing those requirements, but certainly I wouldn't rule out a smaller lower block size in the future.