IFC is basically a huge dictionary of "concepts" in the AEC industry. IFC also includes specifications on how these concepts may relate to one another to describe aspects of our built environment. For example, a "Building" is a concept, a "Site" is a concept, and IFC says that you can relate both of them together such that Site<->Building to digitally describe "A building is on a site" or "My site has a building on it".
There are about a thousand IFC concepts, and hundreds of specifications on how they can be combined to create meaning. This is a lot of data. It is not something that has been well documented in literature, unfortunately, but many OSArch members can help you there.
For different usecases, you may not need all the concepts, and you also might not need all the ways they can be combined. Especially with traditional BIM tools which have to translate proprietary unstructured data into ISO-standard OpenBIM, this creates a big problems for traditional closed vendors. buildingSMART's stopgap solution to this was to introduce something called an "MVD", or "Model View Definition". The objective was to specify what data should be captured in an IFC during this complex translation process. For example, for facility management data, you don't need many quantities. Even for many coordination activities, quantities are not important.
Historically, omitting data and only specifying what's in an MVD makes life a bit easier for vendors and certification bodies. However, in practice, this translation process is full of problems, MVDs are very hard to write, validate, and users lack the knowledge to specify what they want. Even when the data is in there, most existing IFC tools are quite superficial and only let you access data up to a certain level. Well-intentioned users can only do so much when the export process is a black-box and the mapping process is complex, and MVDs are poorly documented, poorly validated, poorly certified, and so on. As you can see, even with the MVD concept, there is very little guarantee that an IFC is actually useful to a user.
So back to your question, there is a little utility right now in decreasing the data in a file to accommodate vendors who just want to translate a bit of IFC data into their own proprietary system.
However, given the number of free and open source IFC libraries for all programming languages, given the growing public test cases for certification instead of black-box certification programmes, and also given the growing evidence that native IFC is practical, you are absolutely right - MVDs, limiting data, and creating weird derivative exports makes no sense anymore.