When one runs against this limit, then one is almost certainly doing something wrong.
Using lots of textures has many obvious and not-so-obvious disadvantages, the most obvious one being that you have no way of knowing how many you can use (at the time of writing the program). Sure, in theory you would query the limit, but let's stay realistic. It's not a very workable (or efficient) approach. In particular, what do you do if you have 17 textures, and the limit is 16? Leave one object black?
Binding one of several small sets of textures at a time as needed is a common approach, but is not the optimum since changing texture descriptor sets is possibly a massively expensive operation. GPUs can typically switch between a very small number of descriptor sets for almost free, but whenever you exceed that unknown small number (which might be something like 2 or 4), you have a complete pipeline stall. That's going to kill you.
So, rebinding textures once or twice per frame is probably no issue, but doing it 200 times is a bad idea. Keyword: batching. When one says "batching" that doesn't necessarily mean draw calls (those are actually pretty cheap with GL). Batching refers to leaving all state (such as textures) as it is. If one changes textures (or state in general) mid-frame, then at the very least care must be taken to sort and thus batch all objects by state.
Ideally, one uses a single small set of textures (never change bindings) where the many different textures are either packed in what's called a texture atlas, or if the hardware supports it (virtually all hardware nowaday does, core since 3.0) different textures are actually layers within the same array texture.
A texture atlas works with even older hardware, but has a few little gotchas (bleeding, derivatives, etc) that you need to take care of. Packing textures into an array texture "just works". All you need is one uniform to pick the right layer.