while they may not be changing their codebase twice a year, code can evolve enough to be hard to recognize, especially in big, intermingled (i.e: poor) codebases which interact with other systems (can someone say microservices?)

Small things change here and there and suddenly you don't understand the beast.

Granted, this is not a general case, but do not underestimate several months work by a team of people.

Eh, there's so much thought built into getting code into production. Things like logging, monitoring, service discovery, orchestration, rollback, authentication, authorization. Couple that with all the other stuff for just coding, formatting style, testing standards, code reviews, version control patterns, allocation of tickets. Then sprinkle in some institutional awareness of who's responsible or who can answer questions about system interaction, connecting to databases, sending email, creating new users.

I'm skeptical that all of that changes often enough to make a rehire less valuable than a new person. Sure, you may have switched to k8s from docker. In that kind of environment, can you really get a new person really productive in less than 6 months? And with the new person, you're never really sure they're actually capable of doing the work, until they do the work.

Ok, sure, if the potential rehire wasn't all that great, it's probably worth rolling the dice. But if they can point to a few successful projects, why not rehire? You know they're a cultural fit. They accept however dysfunctional the organization is, and tolerated it well enough to want to come back. Plus they know a bunch about how to actually get things done in your particular structure.