Another might be that git clone gets the "correct" branch by default. Might be important if your git repo gets cloned by sales, support or whatever for external demo purposes.
Anyway I don't think it makes a huge difference in complexity - it's rarely used for developers' workflows and doesn't even need to be updated that often.
So... why not branch off master and merge back into master?
The fact that a change passed a CI and another change passed a CI doesn't mean they can merge and the result is guaranteed to pass CI. It will often break and if you think for a minute you will come up with really rudimentary examples of this.
The really primitive solution is to call the merge-recipient branch the "develop" and only merge to "master" when you are sure what you are merging is good. You'll be ok if you do it sequentially (no parallel merges to master).
A more complicated solution is to actually test (in CI) "what happens when I merge this" but in hiding, without showing it to others. Even more complicated is to do it in parallel. Gitlab calls it Merge Trains (Premium only). Zuul-CI calls it gate/gating and has a pretty good description here: https://zuul-ci.org/docs/zuul/discussion/gating.html#testing...
When you're ready to merge, have CI test the result of the merge, and only push the merge commit if things pass. Don't let anyone other than CI push to master.
You can set up a bot with a queue to do this, of course, but you can also define "CI" as a shell script. GitHub, GitLab, etc. will automatically close a pull request if you push to master; you don't have to push the button on the website. Train people to not hit "merge" and instead to run a script, something like this which I just threw together:
#!/bin/sh -e
repo="$(mktemp -d)"
git clone https://... "$repo"
cd "$repo"
git merge "$1"
make test
git push
cd
rm -rf "$repo"
As long as GitHub does it wrong, you won't be able to "train people" not to hit the big juicy green button, that should be really a big red "Emergency Merge - Can Break The Receiving Branch" button.
Who does QA on the feature branches, and where? Does each feature branch have its own corresponding deployment? Are they sharing databases with other branches?
This way in case of some unforeseen bugs you can fix master which is production like and then merge that fix also into develop so it is present in next release. If you would develop on master you don't have obvious "production like" place. You could do tags, but somehow it fits better with CI setup and Jenkins.
In our team we have acceptance branch instead of "release branch".
Feature branches are short lived, develop, acceptance, master are long lived branches. You also don't mix stuff because what you really want is one way direction of promoting changes develop->acceptance->master.
That's it, that's the reason.