I don't really see the advantage of separating develop and master.

master isn't strictly necessary since everything is tagged anyway. It just serves as a nice way to see the current release's source code (a pointer to the latest release). You could just use "master" in place of "develop" and have a "production" branch fill the role that "master" does in this model just as easily.

And personally I am not a great fan of having feature branches in the
mainline repository.

They aren't in this model. If you need to share a feature branch with someone else prior to a pull request they can just pull from your branch on GitHub directly.

There is a lot about the document and the ideas that are good, but I
don't follow the whole model. For me master is the development branch –
and if using continuous delivery can always be branched and released.
All major and minor releases have separate maintenance branches. with
bugfix releases being tags on that. This seems enough, I am not sure of
the usefulness of anything more complex. But I may be missing something.

It can be modified to fit whatever the need is, of course, but there is a lot of value in how well it is documented. Any changes made or alternative models used should be well documented too to lower the barrier to entry for contributors. Everyone needs to be working from the same mental model.

Regards,

Brad Anderson