Well, after reading and listening to Jim Gettys, it actually is a kind of bufferbloat. However what Jim Gettys was talking about are unmanaged queues (FIFO) which are too big (unnecesarily). If you use HTB with one output queue as I did and the type of the queue will be FIFO, size let say 1000 packets, then of course you will have a bufferbloat there. Packets will be dropped only after the whole 1000 packet queue will fill and the queue will remain full (supposing there are enough flows to fill them). The bufferbloat will occur in the HTB queues.
But what I’m talking about is a kind of hardware queue, which is after the HTB queues. Even if you use FIFO in HTB and set it’s size to 1 packet (dont ever set it to zero, or you will be screwed 
), the packet will then go to the hardware queue. The size of hardware queue for 802.11a is approximately (according to my measurements) 155 packets. And there is the problem - if the packets from HTB queue go into the hardware queue faster than the physical interface is able to send them, the hardware queue will fill and the bufferbloat will occur there.
What is interesting about this hardware queue is that it never drops packets! It just fills up, stays full. RouterOS does not put any packets into it until some packet is send from the physical interface and therefore makes a space for another packet in the hardware queue.
So if you set a speed limit in HTB that is lower than the speed of physical interface, the hardware buffer will always contain only one packet (unless the RouterOS sends packets into hardware queue in chunks which I doubt). And you can easily avoid bufferbloat in your software queues (for example using short PFIFO, RED or using properly set PCQ).
However if you set speed limit in HTB higher than the speed of physical interface, then the hardware queue will fill and bufferbloat will occur, no matter what software queue you use. This is not the problem of ethernet links, since you know exactly what the physical speed is, but is a big problem for wireless links where you don’t know the exact bandwidth, especially when there is an interference with another wireless networks. The available bandwidth can change dynamically.
So what you can do is to set the speed limit in HTB to very low level - the minimum speed you know you will get from the link no matter what - and avoid the bufferbloat in hardware queue, which will cost you a lot, since the guaranteed bandwidth will be very low. Or you can set the speed limit high and experience bufferbloat in hardware queue.
This is a real pain in the ass. It seems that you actually cannot do speed limitation and QoS for wireless links on RouterOS that would really work. Or is there a way to change the size of those buffers?