First, I want to point out that in git, every
pull is quite literally a branching operation, and every
push is a merge. The
master on a developer's machine is a completely separate branch from the
master on a central repo you share, with equal standing from a technical perspective. I will occasionally rename my local version to
upstream or something if it suits my purposes better.
I point this out because many organizations think they are using branches more effectively than your colleague, when really they are doing little more than creating an additional name for a branch along the way, that won't be saved in the history anyway. If your colleague is committing features in one atomic commit, it is just as easy to back out as a merge commit of a feature branch. The vast majority of feature branches should be very short-lived and frequently merged anyway.
That being said, the main drawbacks of his style of working are twofold. First, it makes it very difficult to collaborate on an unfinished feature. However, it wouldn't be difficult to create a branch on just those times when collaboration is needed.
Second, it makes review before merge very difficult. On this point, you don't actually need to convince him. You can adopt a tool like github, gerrit, or gitlab, and require pull request code reviews and passed automated tests for all merges. If you're not doing something like this, frankly you are not using git to its full potential, and it's no wonder your colleague doesn't see that potential.