I happen to work in a shop with problems that look somewhat like this. We have a non-trivial amount of legacy code, that we just don't have the resources or motivation to fix. In those cases, we've found that the cohesion of doing it the same (wrong) way everywhere is easier to work with than doing it the new way in some places.
If you work with proprietory hardware (think FPGAs), if you want to use the hardware, you have to use proprietory vendor tools, whether you want to or not.
> if the tools are internal then by definition you have the ability to make changes to them.
This misses the point. Having the technical ability to modify the tool does not equal having the real-world-practicability, business-case-defendable ability to change the tool.
> Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling
The point is that in a 20 year, n-million line codebase, neither is "easy", and the pragmatic solution is to do neither.
That hardcodes the source layout? I don't buy that a tool that's being sold for money would do that (precisely because there's no standardization in the C++ world; any tool that wants to have more than 1 customer will have to support more than 1 directory layout), and if the tools are internal then by definition you have the ability to make changes to them.
> Fundamentally: the codebase has worked perfectly well this way for the last 20 years; what's the business case for changing it (at potentially significant cost) just to be compatible with XYZ new tool that everyone is rallying behind?
Well, if you make adopting good tooling in C++ harder than switching to a language that already has good tooling, don't be surprised when developers do that.