In my experience of both high-performance software (e.g. games, number-crunching) and performance-neutral software (websites, most everything else), there’s been one huge advantage of late binding: the malleability/maintainability/extensibility you’ve mentioned.
There’ve been two main benefits of early binding. The first:
- Runtime performance
is commonly accepted, but generally irrelevant because in most cases it’s feasible to throw hardware at the problem, which is cheaper. There are, of course, exceptions (e.g. if you don’t own the hardware you’re running on).
The second benefit of early binding:
- Ease of development
seems to be underrated. In large projects where developers are working with other people’s components, IDEs can read the early bindings and use them to inform the developer (with autocompletion, docs, etc). This is less practical with late-binding because the bindings are created at runtime. It is still possible with late-binding languages if the IDE can infer structure definitions from the code, but since the structure can always be changed at runtime, it’s not so reliable.
Ease of development is a big deal. It minimizes expensive programmer time — and the larger your development team, the more significant it becomes. You’d need to balance that against the flexibility you get with late-binding languages.