With git you have total control as a maintainer. So much control that you can reject an entire pull request just because one single file has a whitespace error. Or put more realistically: nothing goes into your repository without your consent. That's control.
>3. They need meaningful path-based authorization.
Path-based authorization is a hack for a management flaw (throwing projects together into a single repository). Suppose the filesystem maintainer only had write rights to fs/ that would most likely suck when there's an API change to be made that affects files in mm/. Doing two separate commits would introduce non-compilable commits into a bisect workflow. So people should just actually get together and actually talk about their changes and not just commit in the hope that it will be ok. That way, Git actually enforces that you get a handful of the important eyeballs that are said to make bugs so shallow (assuming a project that's not done de-facto-solo).
>4 They need simplicity.
I won't call Git outright simple, but the way it works makes it simple in the long run. Annotating (i.e. rebase -i + reorder + edit) commits something that is, at least was, last time I looked, "impossible" (read: infinitely infeasible) in SVN is one example not to miss in Git. SVN repositories seem to generally have a higher percentage of commits that (try to) fix up mistakes things post mortem again and again: