The commit to master or trunk works as long as you are ok with how it works.
It means that if you have committed a bit of code to master (and haven't pushed it because its not a complete thing) and then realize that you need to work on something else (leaving those commits in an incomplete state) - it becomes very difficult to do that.
Branches exist to separate development efforts and the roles that a given line of code may take.
- You are packaging up a release on master, and now everything other than commits for this are frozen. This stops a lot of developers in their tracks.
- You need to commit a hot fix into master and push it to production.
- You need to work on two separate tasks at the same time.
- You need to hold off on committing some features into the master branch until marketing says "ok"
- Oops, that feature was a mess. Don't commit it to master - oh wait, its already there.
These are just some of the issues that come up with everyone committing to the master branch. If you can resolve these in other ways, then, well, you don't need branches. However, branches are exactly the tool that is used by most processes to resolve these issues avoiding code freezes and awkward reversals of specific commits.
I will also point out that none of this prevents you from having local branches. One could easily pull from master, branch local, rebase on top of master, delete the local branch, and then push that back to the remote master and none would be the wiser. Personally I feel that having branches and merges showing more information about the history of the code is useful, but thats me personally. Maybe your admin doesn't like seeing all those branches and just wants to see the master branch - there are people like that. But that doesn't mean don't branch local - it just means don't push the branches back to the remote and clean up everything before doing that push.