I agree that using a taxonomy for requirements just for the sake of it is silly. Analysts need to apply judgement based on their experience. However, I do see value of the business analyst thinking about differnt categories of requirements even if they don't (and probably shouldn't to avoid confusion) share this categorization with the business stakeholders explicitly.
Each logical group of stakeholders, typically grouped by business division, channel, etc., may have differing and conflicting requirements. The business analyst needs to understand this and enter the requirements elicitation process with this in mind.
Also, we have all experienced the situation where you are elicititing requirements only to ask ourselves, how does this support the overall business goals of the organization. Not that every requirement has to, but they shouldn't conflict with high level business goals.
You can argue that this all starts with stakeholder analysis. Who will you be eliciting requirements from? How are the different groups inter-related? What are possible points of contention? Etc.
For seasoned business analysts this is often second nature. You do all of this intuitively without thinking about it, which is fine. It works. For less seasoned analysts, breaking the task of eliciting requirements into smaller chunks based on Enterprise requirements, Customer requirements, Stakeholder group A requirements, Stakeholder group B Requirements, etc., can be a helpful process for arriving at a final list.
Of course, in the end, you should have a single set of consolidated, non-conflicting requirements. No need to bucket them at this stage in my opinion.