In my experience, an additional gap between working directly on master is many teams don't understand the concept of promoting builds. So e.g. you can build on every commit, then _after the fact_ promote one to an actual release (without re-building). This isn't suitable for _every_ situation, but it is for all the ones I've encountered so far.
Relatedly is "release branches". An alternative is to simply tag the release that went out, which is the same thing. If it needs a hotfix, you branch off the tag, fix it there, then apply that fix (cherry-pick or redo) back to master.
Overall, IME the biggest benefit is the cultural changes it instills in the team: Everything must be good enough to release, and everything goes to the same place. For projects that can afford it (again, most can I bet) its a huge drop in mental effort to understand the state of the world at any given time.
Relatedly is "release branches". An alternative is to simply tag the release that went out, which is the same thing. If it needs a hotfix, you branch off the tag, fix it there, then apply that fix (cherry-pick or redo) back to master.
Overall, IME the biggest benefit is the cultural changes it instills in the team: Everything must be good enough to release, and everything goes to the same place. For projects that can afford it (again, most can I bet) its a huge drop in mental effort to understand the state of the world at any given time.