FHIR tries to model the whole world in the sense, that addresses are abstracted so much that all kinds of addresses could be represented with it.

Optional elements are one of the biggest problem of FHIR. You cannot just ignore them. If you show a physician just part of the data they might misjudge the situation. If you are writing profiles it is best to set cardinality of not needed elements to 0..0, so nobody gets the bad idea of writing that data or relying on it.

FHIR does not even commit to its own way it works. The system and value elements of Identifier and Coding are also optional. That is just madness, and exactly what I mean, when I say that it's trying to be abstract enough for anything.

To read resource metadata you need to already know which FHIR version the resource is. Even if you can, going through the profile information seems like a huge detour and complexity for such a simple thing. I don't know why there's not simply a different namespace in XML for the different versions. Also widely used JSON formats like OpenAPI include the version.

Profiling is an extreme mess. If you write profiles it's extremely difficult to get everything right. If you need to work with profiled resources it is hard as well, as working on FHIR resources directly is too complicated with extensions and everything. So you need to create Models that represent the profiled resources and need to write converters. You need to do all of this by hand, trying to understand the profiles from a technical perspective and trying to understand what the other human that wrote the profile actually meant.

Why is FHIR used? In my experience there's a push to use international standards and FHIR best fits that. It's not a technology selected by the people that actually have to work with it.

The alternative is to have a schema of your data (for instance with OpenAPI) that exactly matches your data model and is optimized for generating code from it. No need to understand the extreme complexities of FHIR and far less work.