This seems to be hallmark of a “Middle” developer. Not so junior that they couldn’t build a working solution that they assume everyone should use, but not senior enough to think twice about whether they should be building it.
The “we should make a common framework” for this line is the dominant thought at this level. Never even a library. A framework. Everyone must do it this way.
The more senior people share concepts and maybe libraries, and allow the team to use them if they see fit.
Part of the motivation behind DRY was to avoid the mess of repeating yourself within a task by updating 17 levels of classes and factories to add a field somewhere. This is mainly solved by using a sane language and not having useless intermediary code.
But you are right: applying DRY between tasks requires good judgement, and sometimes it's best to just copy some similar code around than to prematurely invent an abstraction.
I've worked at bigger companies and there are plenty of folks much higher than 'middle dev' forcing these types of things down the organization's throat.
You can certainly be a mid-level in skill but be a senior/staff/principal at the company, or a senior/staff/principal in technical skill but middle or junior in strategic or design skill.
This kind of consequential decision can happen at high levels. Obviously less often when a truly brilliant developer ends up in a small organization (but that has its own risks.)
In the example, it was determined that they could not afford to let each service solve its individual bottlenecks ad hoc. So a corresponding strategic error was also made/forced at the senior business level.
It's easy to speculate in hindsight, but in this case I could imagine a globally enforced throughput mandate supported by a widely visible and frequently reviewed dashboard, new tools/libraries as needed, and an optional central queue service required to 'compete for business' of the individual service teams.
I can see potential problems with that too, though. In a sense, failure has already happened when growth management is deemed to be too important to be left to capable individuals on decentralized teams.
People use the most practical things at their disposal. If Tim had opted to publish a repository of easy and _simple_ recipes for managing kafka and postgres integrations, while retaining the ability to use original libraries, then I see no reason why it would not have gained traction.
The “we should make a common framework” for this line is the dominant thought at this level. Never even a library. A framework. Everyone must do it this way.
The more senior people share concepts and maybe libraries, and allow the team to use them if they see fit.