Well, it's manual in that when a developer thinks they're done, they open a pull request from feature branch to develop. That's where code review takes place, and as such it's a core part of the workflow. Failing qa might mean additional commits on the feature branch and another pull request to develop. (Develop should really be called testing or qa; historical reasons.)

Git having default branch name be "dev" instead of master/main would really clear a lot of misunderstandings and people thinking "main" branch is the stable one.

It sounds to me like the relationship between dev and main is maintained implicitly. At some point dev and main were the same, and from there, any delta that is applied to dev is eventually either applied to main (if it passes QA) or removed from dev (if it fails).

One more question. What if instead of this dev branch people just asked the QA system to run on their feature branches? Would that generate too much work?

I'm imagining that the flow you describe is some kind of convenient or less expensive version of that.

That's pretty much spot on.