There's a lot here in common with the higher-prestige systems operated by major tech companies. Giant custom monorepos, sometimes with custom IDEs built into them. Big proprietary services for running asynchronous jobs and collecting logs and everything else. Data-driven frameworks for spinning up new services. Bespoke databases. All of it rings a bell.
The one thing in there that really jumped out at me as "oh my god never ever do that" was using pickle for serious persisted data. I can see the upside around letting people who aren't dedicated programmers avoid thinking about serialization but...daaamn. My understanding is that this locks you into a "the API is all the code" situation where you can never change the data layout of any class once you've written it?
It’s not just straight pickle (usually) - there’s a layer in between that allows at the very least for the handling of deprecated fields/new fields/renames etc.
But - after a change - you have to choose either to leave that ‘backward compatibility’ in-place (essentially forever), or put together a job to run (on that scheduler! Hah) to go re-write in your new format. If you care enough, you might - and then you can remove your logic to handle the old names/shapes.
The charm in a lot of it is in its simplicity. It doesn’t claim to very smart, but people get it - and are often remarkably productive.
The one thing in there that really jumped out at me as "oh my god never ever do that" was using pickle for serious persisted data. I can see the upside around letting people who aren't dedicated programmers avoid thinking about serialization but...daaamn. My understanding is that this locks you into a "the API is all the code" situation where you can never change the data layout of any class once you've written it?