ehhh. In my experience, being able to code is a necessary but not sufficient skill for a software developer. The only exceptions I've seen is having some extremely deep expertise in a niche technical field (and even then I wouldn't call that being able to code well, so much as technical domain knowledge).
When I was hiring at AWS the view for my team (RDS) was that there wasn't much difference in expectations between algorithmic coding ability for juniors and seniors. The primary technical differentiator for seniors was architectural and operational. But even more important than those was the nontechnical stuff; mentorship, being able to communicate ideas clearly and succinctly (no point in being able to architect a system if you can't communicate it in a way people understand), interacting with other teams, demonstrating understanding customer and business value, etc.
In fact, my entire point of the critisim is that you can apply the concept to every profession and it will still be valid hence its a banal weird thing.
Saying being a manager or in marketing is about people makes 100x more sense than to say its about writing. Almost all jobs involve people so it applies universally.
But that doesn't mean software is not code. that is still a weird thing to say and wrong.
For most problems solvable in code, there are literally infinite valid code representations of possible solutions (at least in higher-abstraction languages, the space is much more bounded at the assembly level). If you consider the subset of those representations that result in sufficiently performant execution, does it really matter which one is running? This is where most programmers will start mentioning clean abstractions and readability and maintainability, but those are concerns of making the code understandable for people reading and modifying that code. The people are still the driving force.
I'm not arguing for slop here - I definitely care about code quality - but it's important to stay grounded in the reason that it matters: people.