If you really are a senior technical person, you have many valuable skills that are not tied to a tech stack. Otherwise you may have a related title but you are really just a technology domain expert - which is sometimes very useful and valuable, but it's not the same the same thing at all.
So yes, it's helpful that people keep current, and obviously waiting for a new developer to get up to speed on the particular stack is always a cost (and it isn't a couple of weeks, for anyone). However, if what you really need is a senior person, it may well be worth that time.
Seeing this assumes the hiring manager understands how software is actually produced and maintained, not just what their current tech stack needs. It's surprising how often this isn't true, but a contributing factor is how mid level mangers are made - which is related to this discussion I think.
What I'd say to that is, yeah, it's true that a senior dev will have skills that go beyond a particular tech stack -- but if you're working as a dev, then those skills are still tied to your technical knowledge.
You might be great at mentoring... but you have to know the stuff to mentor people in it. You might be great at communicating with stakeholders... but you have to understand the technical constraints of your system in detail to have that communication. You might understand principles of software design and debugging... but you still need to understand the particulars of these technologies to make your design or to focus your debugging.
And yeah, you can learn the tech stack, and a company that really needs a senior dev eventually could do okay to hire a senior dev with out of date skills, and wait for them to get trained up. But don't plan on it taking three weeks, is all I'm saying. To really get to that point of fluency and domain expertise takes longer.
(And also, one of the things that senior devs are supposed to do is evaluate new technologies and figure out when and where adopting them can make sense. If you've fallen so far behind on learning new tech, then it's not clear if this is something you're able to do -- maybe it is, and you just worked for a workplace that stifled adoption of new tech, or maybe you're someone who'll just learn what you need and then stop paying attention.)
While I see what your saying, a lot of your language seems to come from the idea that tech is a progression, that we are moving "ahead" always, and that people get "left behind".
That's mostly not true. While there definitely have been advances, tech is also very faddy and repeats itself. Trends are often reactive, techniques repetitive. Someone who has been around for long enough to see some of these waves resolve themselves is in a much better position to evaluate current and upcoming approaches. Technologists also tend to be myopic, and view the things happening in their own tiny slice of the industry as "what's happening". There is a whole universe of interesting stuff on the go that you are at best barely aware of.
Personally, if I'm hiring senior technical people I'm much more interested in their continuing level of curiosity and engagement with something, rather than particular stacks.
So maybe you are worried that your candidate who has been doing ASP.NET WebForms for the last decade on IIS will have a hard time getting up to speed on your use of TypeScript and React ... but if I find out that she's also being building raspberry PI infrastructure for fun and messing around with the Julia language to implement a cellular automata project I'm not all that worried about their ability to get up to speed, even though none of that stuff will get used by the team.
But yeah, it doesn't take 3 weeks. It doesn't actually take 3 weeks for a new dev already well versed in your technologies, with rare exceptions. At least not to be firing on all cylinders.
The thing is, a huge number of teams really, really need a good senior dev. They often don't think so, and often erroneously think they already have some... but they don't. Instead they have people who had "Senior" (or "Staff" or whatever) added to their title because they'd been there for a little while. And every piece of work the team produces suffers for it. So yeah, it's typically worth the investment.
Now granted, that assumes you are good at identifying talented people. This is actually a big ask - and one of the issues surrounding the OP's questions really comes back to that. I think that a lot of software and technology development suffers fairly systematically from poor quality middle management. One of the symptoms of this is the "ageism" discussed here, but it's only one of many....
then those skills are still tied to your technical knowledge.
I think this is a problematic way of looking at it. Thing about it this way: If you are hiring a fairly general developer or engineer, their overall impact is going to be determined by something like 30% technical/ 30% problem solving and communication / 30% teamwork & fit, leaves you 10% to move around in those categories. In the much rarer case you are hiring a domain specialist, it is something like 60-70% technical. But you probably aren't hiring someone like that, or shouldn't be very often.
Focusing the hiring too much on that first 30% impact gets you in trouble.
If you’re competing as a “general developer” with ten years of experience, you’re a commodity that is competing with everyone else and if you aren’t knowledgeable about the tech stack we are using, you’re at a disadvantage. The last thing I want is to hire someone who has been doing Webforms for 15 years when I can find someone that has been keeping up. Why should I have sympathy for someone my age who didn’t have the wherewithal to keep up when I can be aggressive about it?
I know developers in thier 30s/40s/50s who are both great developers/architects and have current skills. Why would I settle?
I think you missed the point I was trying to make, I’ll try and summarize. There are two parts. If I’m hiring you as a 10 year veteran “general programmer”, I’m going to be very interested in the non-tech-stack skills you have developed (i.e. the other 60-plus percent of your impact). And let’s be honest, the vast majority of the 3 year experience “general developers” are weak there. The other point is that technology isn’t a straight forward progression, so while it isn’t great if you have been “stuck” in a tech stack you consider obsolete, by itself that shouldn’t be enough to reject you.
Two other points: First, of course when hiring you want to find the “perfect fit”, but you almost never do, so you have to make tradeoffs. Hiring an inexperienced person with the “right” tech stack when you really need to bring experience into your team is a common anti-pattern. Secondly, as a hiring manager you need to properly understand the difference between “10 years experience” and “one year of experience, related ten times”
Agree with all this, but I'll also say that if you're an experienced developer who hasn't kept up with the times, that's not just a fact in itself, it's also a signal about what kind of developer you are. Most of the best developers are active learners who are always trying new things just as a matter of course.
So if you only know old tech, I'm a lot quicker to believe that you're a "repeated ten times" person.
So yes, it's helpful that people keep current, and obviously waiting for a new developer to get up to speed on the particular stack is always a cost (and it isn't a couple of weeks, for anyone). However, if what you really need is a senior person, it may well be worth that time.
Seeing this assumes the hiring manager understands how software is actually produced and maintained, not just what their current tech stack needs. It's surprising how often this isn't true, but a contributing factor is how mid level mangers are made - which is related to this discussion I think.