In Gitflow Workflow, an hotfix is a branch that is created from master and in the end is merged back in master AND in develop.
The general (and well known) idea behind the "don't directly commit on master", is to have in master, a state of your code that is completely safe to deploy in production.
However, it can serves other means. For Github, the master also serves as a tracking tool to know when a feature is put in production. If you commit on another branch and then fast-forward master on it, you will lose the merge commit, and by extension, you'll just put a lot of tiny commits in your master timeline, losing the ability to revert a whole feature by simply revert the previous merge.
Another problem with this approach, is to know WHEN you can release/deploy. If everyone commit on master, you will have to synchronize all the development to have a coherent state of your code. For monolithic releases with a clear scope, it can be ok, but in my case, as an integration developer, features come and go and you have never a single point in time when "all features are done".
However, not commit in master does not mean having a branch master and a develop. As pointed in the Github presentation, if you do a feature branch workflow, you can work only with a master, creating a branch for each feature, and merges them back in master (without fast-forward) at the end.
In my humble opinion, Git Flow (master/develop + features/hotfix/release branches) is more adapted in a context where you don't really know when you'll have to release it (not at each feature done), and when the last release is often the one to hotfix. A gitflow chart can be convoluted, while a feature branching workflow is often more simple to read. The "noise" is often due to release/hotfix commit in what will be deleted branch some minutes after.
Example for Gitflow
Example of graph for Feature Branching Workflow
