Separate business or system analysts managing requirements documentation weren't (and aren't in the many places where they are still a thing) about developers being “code monkeys” with limited and not particularly valued skills, in fact, it was and is usual for such analysts to be considered inferiors to the programming staff who do work that is beneath programmers worth.

The reason they exist is because the organization values (or is subject to mandates for) documented requirements, and doesn't want programmers to have to bother with the tedious work of developing and maintaining them, focussing on actually developing the software.

Thank you for your perspective.

Was this always the case though? Perhaps my position is colored by my experience working for a former IBM manager who thought of programmers as those who “just write the code” based on the requirements written by the “more senior” business analysts.

That particular experience reeked of superiority of managers, project managers, and the business analysts who worked directly for them. I admit that my experience could have been anecdotal, however I’ve asked several senior programmers who were active in the nineties who have confirmed the relationships were by and large toxic at the time.

Correct, but perhaps unions didn't arise from that because the model failed---that era of Silicon Valley died in the dot-com bust.

The second generation of dot-coms that succeeded centered developers as domain experts and essential to company survival (broadly-speaking; there is certainly variance).