Are you afraid of having to push yourself to the office this weekend, or starting Monday on a bad foot? Just like you don't start writing a brand new piece of software an hour before leaving for vacation - you don't push to production on Fridays.
Also, Fridays are often used for huddles. So, pushing on a day like Wednesday is way smarter since you can have critical issues squashed by the time it comes to the retrospective, which requires signs of improvement obtained from the past iteration to validate the value of your team.
This saying is born of long experience that if one release all week is going to break, it'll be the one someone rushed out on friday ;) No matter how you slice it, pushing new code always has a level of risk.
A sort of gold-plated ideal of CI/CD is the ability to push to prod any time. It's important that engineering have the confidence that they could push to prod any time, but less important to actually do so.
The reality is users don't give a crap if you don't push to prod every day; and in most cases they won't even know or care if you release on a slower cadence. Also you often have marketing/support/product management reasons to choose exactly when and how often to release new features to customers. Your support team will not thank you for releasing new features during their busiest period of the week; and marketing won't be happy if you release something right after they've done the weekly email without mentioning it.
I suspect many companies hit this balance:
- push to UAT on every green build
- ensure the codebase can be pushed to prod at any time (eg. for hotfixes)
- actually push to prod on a much slower cadence, accounting for business needs, at the highest rate that actually provides some value to users
- and/or you might use feature flags for greater control over deployment vs release
So, am I afraid to push on fridays? No. Would I choose to push on fridays without a compelling reason? No.