Job descriptions act like a constraint on the human complexity of a team or organization. They help codify the way people conceive of modularizing known workflows and discretizing for the purposes of having employees solve them.
Crucially, a job description defines the boundaries of what an employee can say no to -- "that's not in my job description."
In the modern hiring landscape, this would be immediately met with vapid criticisms, like you are not a team player or you won't "wear many hats" or whatever.
But the benefit of job description boundaries is not related to entitling programmers to be whiny and complacent about tasks they don't like. That's naive. The reason it's good to empower your workers to tell you no, especially knowledge workers, is because it preserves organization structure and planning. It highlights bottlenecks for you and points out the discrepancy between what you need and what you have. Otherwise, while your machine learning expert is repressing her fury over being assigned to clean up some legacy Rails codebase, you might be off playing golf thinking you've got your Rails maintenance needs correctly covered, when really you don't at all (and you're leaving money on the table by not extract the full value from your machine learning engineer that you otherwise could).
This, by the way, is perhaps the biggest hallmark of a good manager. Good managers will act like double-sided adapters who process arbitrary inputs from the business-problem-stream on one side, and turn them into collaborations with subordinates that fully respect those subordinates' specialities, aptitudes, and goals. That is a damn hard job, and when done properly it is big justification for the increased compensation and status usually given to management-level employees. Unfortunately, many modern firms do not expect managers to do this, and instead they seek to build teams of so-called "full-stack" developers, for everything, so that managers are only receiving business problem inputs and never doing the actually difficult part of turning them into workflows that show respect for subordinates (... you know, managing them).
In fact, I would argue that this is exactly what it means to even have a business model at all. If your "business model" involves hiring people and then screaming at them to do whatever they are told, instead of what they are good at or motivated to do, because "that's just how jobs work" then in effect you actually don't have a business model. You have not yet done the hard part -- figuring out that double-sided adapter layer that translates real world business concerns into things that disparate specialists want to do and won't refuse to do.
When I read this by the Etsy CTO, it strikes me as a big, whiny excuse to try to hire more people who are "arbitrary work receptacles." That seems to be what he is trying to describe as "engineering" -- He uses words like multi-disciplinary and messy, when really he's trying to convey "I want you to do whatever arbitrary work I say, regardless of how poorly it matches your aptitudes, interests, or goals."
I feel developers should more strongly demand legitimate job descriptions, and ask during the hiring process for specifics on the ways that managers will be held accountable for protecting the job description, instead of forcing employees to bottomlessly compromise on their goals in order to be arbitrary work receptacles.
It's not about mere displeasure over having to do arbitrary tasks. It's about the fact that a lack of planning or modularity codified through job descriptions is bad for business. Properly respecting employee aptitudes is a sign of a healthy business. Demanding arbitrary cross-functionality all the time is a sign of needless chaos. We can see this clearly in software itself: if all of your classes make everything public, silently mutate each other's state, and everything grows purely by attrition with no attention paid to e.g. Single Responsibility Principle, it's a huge red flag of bad code and impending system failure. But we bury our heads in the sand when the same ideas become apparent when managing people complexity instead of software complexity.