It has to do with how quickly you can iterate on your production software and what the distance is (in terms of time) between a developer committing a change and that change making it out in front of an end-user.
In traditional enterprise software (e.g. insurance) the deployment cycles are long because the organization are large, heavily layered, and extremely resistant to change. There are many reasons for this, some sensible and some not. (And then some that are legislated - they fall into both categories).
For a startup that is trying to build a service, or a mid-sized corporation, particularly in the ecommerce space, the faster you can change a deployed solution, the better off you are.
Say you're running a large ecommerce website and a bug is discovered on the user account page. It's a "P1 issue" that needs immediate attention, i.e. as long as the bug exists, revenue is impacted.
In a situation like this, you want to be able to identify a fix, commit it, and ship it to production ASAP. This becomes an issue in traditional organizations where the "developers" are different from "the network people" who themselves are subdivided into database/network/sysadmin/etc. These groups are change-averse and tend to gate releases into maintenance windows. Which makes sense, but can hinder rapid deployment.
If you don't have a traditional Ops team, there's no stakeholder who feels you're impinging on their fiefdom when you wantonly hit the deploy button. (Though I don't mean to imply that you shouldn't have discipline around releases).
The question you're asking is very relevant for teams making the transition to processes like Agile and infrastructures like Cloud. Because these things are disruptive, they lead to change and break-down of traditional org structures. A dedicated QA department always seems to be one of the first things targeted. (Though I don't necessarily think that's a good idea).