Because building for extensibility adds real complexity for a hypotetical need

If you want the code to do something different later, change, replace or extend it then... when you actually know what it needs to do

I am not sure that is something that applies 100%, but I understand the concern.

It is my understanding that we should try to build solutions to current problems, and be open to future use cases that could involve small additions in functionality.

It would be stupid to design an unmodifiable system just because some parts can be deleted and we are not sure what future needs are. Code should always be easy to extend, in my opinion.

Conversations like this are always difficult to discuss at a high level because the way we implement the words we use can be very different. Code can be written in a way that a lot of complexity is added in order to make it extensible, or it can be written in a way where simplification is used to make it extensible. Both authors would agree that extensible is good.

That is an excellent and pragmatic point of view.

It's not an absolute and there are occasional good design decisions made in the name of extensibility

But what is an unmodifiable system? If it's code in your control, it can be changed, right?

If it is easy to understand, then it is easy to extend.