Another answer to complement derobert's.
Firstly on modern Intel CPU's the manual is out of date. Modern CPU's have high resolution timers, and modern Linux is tick less - literally meaning there are no timer ticks. Thus all those comments making buckets big enough to hold the tokens in one timer are irrelevant. In fact the bucket analogy was only there to help the user understand the interaction between the timer granularity and send speed. Now that Linux has nanosecond timers on modern hardware it loses it's usefulness.
For TBF the burst parameter is the number of bytes that can be sent at unlimited speed before the rate limiting (specified by rate) kicks in. Once rate limiting has kicked in the only way to burst again is to limit your sending to below that rate.
For example, lets say your tbf burst parameter is 10K bytes, and your tbf rate parameter is 2K bytes/second, and you are currently rate limited (ie the burst is exhausted, so you are limited to sending at 2kbps). If you voluntarily reduced the speed you sending at to 1Kbps for 10 seconds, you would accumulate your 10K bytes burst allowance back again (= (2000 [bytes/sec] - 1000 [bytes/sec]) * 10 sec). Keeping it below 1kbps for more than 10sec would have no effect because tbf does not allow you are not allowed to accumulate more than the burst parameter.
If you stopped spending entirely then you would get your burst allowance back again in 5sec (= 100000 [bytes] / 2000 [bytes/sec]).
You don't have to get all your burst allowance back to use it, you can use as much as you have accumulated.
Another way of looking at this is: you are allowed to send burst bytes at unlimited speed, thereafter your long term average speed can never exceed rate. However, because it is a long term average, if you drop below rate you are allowed to catch up by sending at full speed - but even then you are only allowed to send at full for at most burst bytes (and if that doesn't allow you to catch up you can't).
The other wrinkle is TBF has two of these rate limiters, and your traffic has to pass through both. In the second one, the burst parameter is called mtu and, and the rate is called peakrate. You are supposed to use this second one to limit the speed the first one can send it's bursts at. Using this second one is optional, and if you don't use it the bursts are sent at device speed.
Finally, tbf has a limit parameter. If the program persistently sends faster than rate, then packets will build up in the queue. There isn't infinite kernel memory, so limit says how many bytes can build up before the kernel starts discarding packets.