If the meaning and intent of the BABOK definitions was to define 3 different abstraction levels for one type of requirement, then I would agree with Tony and Kimbo that this would be unnecessary overhead. However, the BABOK classification is intended to differentiate between 3 distinct and different types of requirements. There is no hierarchical or linear or sequential relationship between the 3 classes.
Contrary to Tony's statement, the BABOK actually does suggest decomposition as an analysis technique for all 3 classes. However, decomposition for each class would start at a different place and produce quite different results. Perhaps if I go back to my 'fruit' analogy as an example, that might help. If you think of an orange as a 'system', then you might decompose solution requirements for an orange into peel, pulp, segments, and seeds. Stakeholder requirements, however, would be akin to cross-segments cuts across the orange. You could not decompose any single cross-segment into the same peel / pulp / segments / seeds of the orange system. Stakeholder requirements are not intended to represent a high-level view of the orange. Stakeholder requirements are valuable for certain purposes - to assess the needs of stakeholders, to identify the impacts of system changes on given stakeholder organizations, and to trace requirements back to stakeholders (for communications purposes, engagement purposes, etc.) as examples.
The BABOK does not recommend or even suggest that requirements should be defined across all 3 classifications for any given system or solution, and I do not believe that any participants in this discussion would recommend that either. The class of requirement to be defined is the choice of an informed BA, as appropriate for any given project or set of work. BA's who focus on software projects might only and always use the solution requirements class. Each class has a different purpose, different modeling techniques, etc. An enterprise model cannot be represented by a context diagram or modeled through information flow / data flow diagrams - but these techniques work very well for solution requirements.