Many years ago there was a 2GB limit associated with the bi log. If the active bi log hit 2GB the db would crash and you would not be able to recover because recovery takes (roughly) 2X the bi space as was active at the time of the crash -- and if you crash because you used too much BI you are in an infinitely recursive logic loop that you cannot get out of
To prevent that from happening -bithold could be set to some value well below 2GB. 900MB being a common value.
Starting with v9 the 2GB limit was removed and the need to use -bithold for that purpose eliminated.
But many other improvements have since been made to the DB engine... some of those improvements have been focused on greatly increasing transactional throughput. An unplanned side effect of those improvements is that it is now possible for poorly written code to write vast amounts of data to the bi log very, very quickly. So you can potentially fill up your filesystem quite rapidly. Maybe even before you have time to notice and do something about it. Luckily that is not as fatal an event as the old 2GB bi limit -- it is easy to add more disk space and recover. But it is a pain in the neck and users tend to frown on long outages so -bithold is still a handy option for limiting excessive bi log growth. A good idea is to set it to either 1) a "reasonable" value for your application (if you know such a value, which is uncommon) or 2) a fraction of the filesystem size -- such as 25%.