Ultimately, the decision to deploy at end-of-day or on fridays, or at EOD on a Friday comes down to the degree to which you trust the assumptions that are baked into your deploy process.

Deploy processes generally put a lot of faith in tooling, monitoring, logging, etc. If those things aren't present, then deploys are inherently risky. Performing an inherently risky process at EOD, when nobody is around, only increases the risk.

At the very least, a botched deploy at EOD, or at EOD on a Friday, kills any goodwill that you had with your coworkers, because they will be notified and brought into any outage that you cause at EOD on a Friday.

Who wants to fix a broken system while in a panic-induced stress, at a time you are supposed to be enjoying leisure?

The following articles highlight many of the assumptions that must hold for a deploy to succeed. If those assumptions don't hold, you broke things, at EOD, on a Friday. Enjoy that leisure time!

https://clubhouse.io/blog/dont-deploy-on-frida-3-other-unwritten-rules-of-software-engineering/

Why not to deploy on a Friday?
Joel mentioned in StackOverflow podcast #24 that it’s FogCreek company policy to not ship software on Fridays. However, he didn’t elaborate as to why. I agree. At my employer, we deploy on Thu...

https://hackernoon.com/deploy-on-fridays-or-dont-qg2y32jk

https://charity.wtf/2019/10/28/deploys-its-not-actually-about-fridays/

https://medium.com/openclassrooms-product-design-and-engineering/do-not-deploy-on-friday-92b1b46ebfe6

Why you should deploy on Friday afternoon
Take ownership of your software by automatically pushing to live