Deploying when it's done doesn't necessarily mean there's no change control.
Peer review (as in git workflows with pull/merge requests and audit), automated testing, pipelines, CI & CD are all just a modern form of change control, where we've remove the checklists from humans.
One persons professional is another’s bureaucratic. There’s no one approach right for every team in every situation. It sounds like they’ve find something that works for them for now and that’s great.
I disagree. United States department of defense, advanced research project agency and the software engineering institute at Carnegie-Mellon university disagree as well.
I'm very much inclined to defend their methodology and position on this since that is their core area of expertise, and I've experienced it working on a very large scale (tens of thousands of servers) rather than a bunch of hacking efforts at some company on the InterNet.
Move fast and break things. If your go-live is fast, any mistakes are fixed fast. Besides, if it's a webapp, chances are anything they break is relatively benign, not catastrophic and hurting their bottom line - that's assuming they have a bottom line.
Plus, if they provide a good service, people will forgive them. Twitter was terrible in the first years it was growing in that regard, yet people kept coming back.
So they have no change management process in place and are basically hacking on it 'till it works. Very professional.
Does not look like they ever heard of the capability maturity model, either.