[MasonOfWords]

Service interfaces should be well-typed. Almost by definition, the cost to update a service interface will be a fraction of the time associated with updating its consumers and testing their integration. Dynamic types can lower a part of the cost (although not by much, in comparison to modern languages and frameworks), but add more expense in many other ways.

When operating at any sort of scale, a system that's "easy to change" stops sounding virtuous. Communicating and integrating service changes effectively is usually more expensive than making the changes themselves, for a large organization. Providing service descriptions which can be converted into static types (e.g. swagger) is very cheap, and can prevent a host of expensive human errors.

In truth, poorly specified services or documents can end up impossible to change, since the risk and impact of doing so is difficult to size (or the exercise of doing so costs more than the change is worth).

[cle]

A system that's easy to change is very important at scale, unless you want to write a new API or service every time a new business requirement arises.

In many situations, a true statically-typed service interface can be nearly impossible to change, or even add fields to. Adding new schema versions (particularly for write APIs) or dynamic/polymorphic schemas that change based on the input are extraordinarily useful and very easy with dynamically-typed interfaces, but can be very difficult with strict statically-typed interfaces, particularly the kind that e.g. Java nudges developers towards.

There are some hybrid frameworks that mix dynamic and static typing, which solve some of these problems (e.g. protobuf, Avro, Ion). They make reasonable compromises.