I'm afraid I'm not familiar enough with MySQL to understand the analogy you're making there.
As for wording, don't call it a bug. Say that it's a necessary side effect of making money with HFT. It's an inherent design limitation. The word "bug" implies that it can be fixed, that you can theoretically do HFT at the same speed as you are now without any quote stuffing if only you had perfect code.
Let's take a vaguely similar example of streaming audio. I worked on a near-realtime streaming audio product for a while so it's something I'm familiar with. Latency and reliability trade off pretty directly. The product I worked on defaulted to a latency of two seconds. This made it pretty robust against network hiccups like wifi interference, but the substantial lag made it annoying or just plain unsuitable for some applications. It was possible to adjust the latency (although this was an advanced technique to the extent that we hid the setting pretty thoroughly) and you could get it down to a fraction of a second and still have the system work overall, but it would be much more prone to dropouts due to network problems.
Now, there are some things that could be done to improve this problem absolutely, like adding forward error correction to the protocol, but nothing is going to eliminate the tradeoff entirely. Because of that, I'd never describe it as a bug. If someone complained about the latency, I told them that it was an unfortunate but necessary consequence of ensuring reliability. The latency can be eliminated easily, but at the cost of less reliability.
Likewise here, quote stuffing is an unfortunate but necessary consequence of HFTs. It could be lessened or eliminated by making HFTs less HF, but you don't want to do that, because you feel that the Hest possible F is more important. I call the writing weaselly because it portrays quote stuffing as completely unavoidable, but the real scenario is that quote stuffing is completely avoidable, it's just that you prefer to make more money instead of stopping it.