I'm not sure which side you're putting me on, because I think named types are important for exactly the same reason that named fields are. A customer should not just be a pair of str, int in the same way that an age should not just be an int and a name should not just be a string (and using an int field called "age" is a poor substitute for using an actual age type).
I was thinking of you as on the domain modelling side (same side I am usually on).
You are right, I should have gone further with the example and used Customer{ age: Age, name: PersonName}.
Why not go further? Customer should be a subtype of Human, which contains subtypes DoesInteractWithCompany and HasNeverHeardOfUs. Customer should have subtypes for each country they live in, and PersonName should probably be split into FullName<FirstName, LastName> for flexibility.
The purpose of a model is to represent salient features of a domain (both the data, behavior, constraints.) In the context of this discussion we are particularly interested in modelling behavior and constraints. As your examples illustrate, it is possible to do a poor job, e.g. model at the incorrect level of abstraction (Human is not salient unless you have a concrete need to model Customer's of other Species), or to introduce specious abstractions. The fact that forming useful domain models is non-trival does not render it worthless.