It's probably not realistic to expect Veeam to be able to replicate at a very small block sizes as this would potentially have negative impact on the performance of backups in general. Trying to account for a large number of blocks has very high overhead, and it's the ability of Veeam to compress, dedupe, and manipilate blocks very quickly that provides for many of it's innovative features like Instant Restore, and fast file level recovery.
In the end, the size on disk is relatively "non-important" because the cost of disk is "cheap". However, the cost of bandwidth is still expensive in many areas. For example, I can buy an enterprise capable iSCSI storage system, with 32TB's of storage, for ~$7,000. However, my 10Mb WAN link to my remote datacenter costs me ~$5000/mo (counting the costs of the circuit on both ends).
So, what I'm hoping for is for Veeam to decrease the amount of data that actually send over the wire. For example, if I have a 256K block, and I change 1 byte, I don't want Veeam to send the entire 256K block over the WAN. Instead, I want Veeam to basically read the new 256K block, read the existing 256K block on the target, and then only send the bytes that changed in that block using something like the rsync algorithm. This will not reduce the size of the rollbacks, but will reduce the size of the data that has to traverse the WAN for small block transaction workloads like Exchange and SQL.
I have no idea what solution Veeam will actually implement, but they understand the issue, and they're an innovative group of guys, so I'm sure they'll come up with something. If they figure out a way to use small block sizes, well, that would be awesome too, but I'm just not sure how harmful that would be to the performance of other features in the product. Simply decreasing the data that has to traverse the WAN is good enough for me.