Let me rearrange some of your points:
> - it runs on PHP
> - it doesn't use composer or any dependency management. It's all require_once.
Great --- explicit dependencies are better than magic. Personally, I'm a fan of require rather than require_once, because of some history, but require_once is mostly fine.
> - it doesn't use any framework
> - no MVC pattern of course, or whatever pattern. No templating library. It's PHP 2003 style.
This is the proper way to run PHP. Can you imagine if they used frameworks? It'd be a slow mess, with about 70 different frameworks. At least this is likely a bare metal, fast mess.
> - this code generates more than 20 million dollars a year of revenue
> - team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge.
So you've got 3 junior people managing 20M of revenue
> - productivity is abysmal which is understandable. The mess is just too huge to be able to build anything.
> I have to find a strategy to fix this development team without managing them directly.
> This business unit has a pretty aggressive roadmap as management and HQ has no real understanding of these blockers. And post COVID, budget is really tight.
HQ doesn't understand the process, can't even budget a manger, because apparently it's not your job to manage them. I'd bet their requirements are unclear and poorly communicated too.
> - the routing is managed exclusively as rewrites in NGInX ( the NGInX config is around 10,000 lines )
Great, the routing is one place!
> - no caching ( but there is memcached but only used for sessions ...)
Do you actually need caching? You didn't say anything about the performance, so I'm guessing not.
> - In many places I see controllers like files making curl requests to its own rest API (via domain name, not localhost) doing oauth authorizations, etc... Just to get the menu items or list of products...
Curl to the same server port is a bad pattern; yeah. Localhost or domain name doesn't make it better or worse. Figure out how to make those a call to a backend service maybe? Are you also saying this is running on a single machine (I think you are, but you didn't mention it)
> - it has been developed for 12 years directly on production with no source control ( hello index-new_2021-test-john_v2.php )
Ok, check in what you have, and make a deployment procedure that doesn't suck, and set things up so you have to use the deployment procedure.
> - no code has ever been deleted. Things are just added . I gather the reason for that is because it was developed on production directly and deleting things is too risky.
If you can, run profiling on the production site to see what code appears to be dead code, and run down the list.
> - the database structure is the same mess, no migrations, etc... When adding a column, because of the volume of data, they add a new table with a join.
Depending on the size and volume of the database and the operational requirements, this is kind of what you need to do. Do you have anyone with operational database experience who could help them consolidate tables, if that's what's really required? Is the database a bottleneck? You didn't say that, you just said you didn't like it. There's ways to add columns and migrate data, but it requires either downtime or a flexible replication system and some know-how. Consolidating the tables without at least write downtime is going to be a lot more challenging than if they had the opportunity to add columns at the right time... of course, sometimes having tables with a join is the right thing to do anyway.
Is there budget for a staging system, complete with enough database instances to test a data migration and time to do it? Maybe focus on developing a plan for future column additions rather than trying to clean up the current mess.
> - JS and CSS is the same. Multiple versions of jQuery fighting each other depending on which page you are or even on the same page.
jQuery is pretty compatible right? You can make a list of all the pages and all the versions and maybe make time to test updating the pages with the oldest versions to newer versions, etc. Again, a staging system would help with testing. Developing a testing plan and running the tests is something that doesn't require much from the three overworked developers, but could be offloaded to a manager.