I have worked with a number of codebases where we did that.
In fact, I have worked with a number of codebases where I was the one who deployed that, because the app process could already do the relevant level of restart without dropping a request, and the leak was slow enough and hard enough to find that I couldn't justify keeping going until I -did- find it.
This continues to annoy me, but having made sure the leakiness wasn't able to -increase- over time without us spotting it immediately, I'm still convinced it was the business-correct decision.
I once worked on a project where a critical system started to leak memory during a critical weekend-long event. We basically took shifts every 4 hours to log into the boxes and manually rolling-restart the affected services.
We did find and fix the leak the following week once the event completed and traffic dropped to normal levels. But sometimes, you got to do what you got to do to keep the app running.
I was more thinking of some mad lads who turned off python garbage collector and just restarted the process when running out of memory. Apparently it gave huge performance and cost boost
