Point 2 is very interesting. Any anecdata to corroborate?
Separately from deployments, in some less-than-ideally run organisations, management may whimsically change its mind about what the number one priority is from day to day. Two-week sprints can shield the delivery team from this, by acting as some kind of low-pass filter on thrashing priorities, to create space to get a few things entirely done.
Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a story on day N might mean it goes out on day N+4, but finishing it on day N+1 means it'll take two more weeks, day N+18. That's where the urgency came from: that "tax" of lost time due to infrequent deploys. So there was a lot of pressure to get things into a given sprint. Hence, sprint commitments.
Now, on the same platform but with frequent deploys, we still have pressure to get a story done by a certain day sometimes, but the sprint cadence no longer affects our ability to do that. It goes when it goes. Without that pressue, we realized that sprint commitments didn't serve much purpose, so w stopped doing them, and we haven't missed them.
That's what I was referring to - it's not the sprint that matters, it's the "tax" on deployment time, which varies depending on where you are in the sprint. Take that away, and you stop caring where you are in the sprint, like a teenager in summertime losing track of the days of the week.
The motivation to batch releases was largely driven by a desire to do full end-to-end integration testing of changes between a number of entangled backend and frontend systems. It often took days to stabilise all the components in the single pre-production staging environment used for end to end integration testing, then run through the test plan. Perform batched end-to-end testing of system was the process bottleneck.
Monthly releases created similar crunch dynamics of changes being delayed by a month if they weren't stable enough to enter the monthly test cycle. Since end to end testing is the bottleneck, you don't want to feed in low quality inputs (rushed changes that are likely to cause issues and then trigger re-tests of the entire slow end to end test process).
I'm not saying this is the best way to do this, it definitely isn't, but there can be some reasoning behind it.