What is ridiculous is when not releasing on Friday means that "your metrics go up and that is bad". This is one of the reasons I hate metrics for software engineers. I should be able to put up a PR any day of the week without holding back committing and PR'ing just because there's a natural 2 day delay that will fuck up my metrics.
I will decide if this is something that needs merging now and be out in an hour even though it's Friday or if it can wait. And for that I need to not have perverse incentives. Just like I need to not have perverse incentives to make your Thursday cutoff by bypassing good engineering. If I can merge now or in two hours and it makes just a two hour difference and nobody cares for some dang metric, then I am more likely to take the time to add that one extra test that catches the bug. Before it hits a customer.
But in no way do I ever want to be restricted ever again from having a fix roll out within the hour. Our hourly deploy process (fully automated) is awesome. Never. Again. Without. It.
Sounds like your current/previous companies have heavier weight release processes that reduces how often releases go out?
Yes, that probably describes 98% of companies. So what?
Weekly releases (or slower) is appropriate when you rely on users to update their software or firmware. Most mobile app development does this.
So good practices are not widely used; therefor the state of the industry on average, is poor.
I'm sorry you've had bad experiences but it absolutely is how it works. When it comes to web based SaaS software, all high functioning organisations release multiple times a day. Daily releases are a bare minimum.