It doesn't feel like this applies here. 6-7 years ago a decision was made to go with stored procedures over using an orm or at least implementing db logic in the application code.
Along with this, they also chose to split the responsibility for code and sql across two teams.
6-7 years ago, plenty of other options were available. In fact, the sharded MySQL solution that they use now was already possible back then.
It sounds more like they made some architectural decisions based on the companies org chart and it came back to bite them in the ass hard.
The constraint may have been knowledge. They may have made a very reasonable tradeoff to forego learning "best practices" and "proper architecture" to just get something out the door. The original developer may have just graduated with his philosophy degree and never have written more than a bash script. Hard to say.
Given the size of the company, the architecture didn't grow along org charts (that is a very real phenomenon in large companies!). Rather, the org chart grew along architectural lines. Regardless of cause, it is a pretty significant smell and can tell you something is (or will be) wrong.
Along with this, they also chose to split the responsibility for code and sql across two teams.
6-7 years ago, plenty of other options were available. In fact, the sharded MySQL solution that they use now was already possible back then.
It sounds more like they made some architectural decisions based on the companies org chart and it came back to bite them in the ass hard.
edit:typos