I butt heads against stuff like this from other dev's all the time, and a lot of it stems from obsessing on one tiny part without seeing the bigger picture. That's what happened here, you focused on the processing so much, you neglected the data gathering side of things.

It's like the "conventional wisdom" of "reducing the number of queries" through JOIN/UNION. Often it's really good advice, but more than once I've had the fact that you get a larger data set and have to spend more time on tracking things like "section/category" changes, that running multiple smaller queries is in fact more efficient. Why? Less data moved around on the network since each row is smaller, POEM (prepare once, execute mostly) can pre-set most of the query requests, and it's easier to process if you've got one result set of your "categories" and another of the child rows. You end up with both a smaller memory footprint, and less network connection / socket hogging.

Better still it's often more digestible code to understand than what complex JOIN gives you, even if you end up flipping the bird at what the majority of developers believe like it was the gospel.

That said, you did the most important thing you can do when making these types of decisions. Build them, and test them. It's amazing how many people will just blindly believe what they're told, then blanket apply it to every situation without verification.