That's true, but not the whole story. Assuming 16B keys, and 1 KB value, with 10x amplification factor in LSM tree, the calculation is (10 * 16 + 1024) / (16 + 1024) ~ 1.14. This includes the write of the value to value log.
The thing about value log rewrite is that you can control it. It's not inherent part of the design. Even assuming that you're rewriting once the validity reaches 50%, which gives you an amplification of 2 for values, that's still only ~ 2.12 write amplification factor.
Now compare this with a typical LSM tree. To go one level down, that's 10x write amplification. Both keys and values need to be rewritten, period. This is still close to 5x less writes than typical LSM tree.
Sure that could be done, and we might actually do that. But, in general cases, you need the keys to be in sorted order, and not random order.
However, irrespective of the "wastage" that occurs during a read lower than 4KB, an SSD can easily do 100K reads per second for a 4KB block. At that rate, the iteration of Badger is as good as the linear iteration done by typical LSM tree like RocksDB. So, that's not a disadvantage, it's the design of Badger. We're trading more random reads for much lower read/write amplification, and smaller LSM tree sizes.
During log compaction / rewrite, we do order the logs by keys.