It's not a horrendous idea, but if it's just 'voodoo', it's probably not going to help you much.
However, there are two reasons not to let this be the end of your investigation into improving your performance.
One is future scalability. If your outages are the result of load, a certain number of queries, a particular query that hits a caching, query compilation, or btree indexing bug, or other issues that currently recur on a daily basis, they will probably occur more frequently as load increases over time. Nip that in the bud.
The other problem is that I suspect you will need to halt incoming requests from dependent services during your restart. You've just created an operational cadence. Every time some daily task needs to be run, it will end up tied to your restart. At some point, you'll have these massive rolling restarts that take six hours (I am not exaggerating here, I have seen it happen at more than one company) and no one will remember why everything needs to be stopped and restarted in the middle of the night.
My recommendation would be to monitor the SQL process and restart as needed. As mentioned by an earlier poster, SQL doesn't have the memory leak people think it does (and I say this as a person who was on the MSSQL team in the mid-90s). You want your database server to use almost 100% memory and CPU. Anything less is wasting resources.