One thing the article unfortunately fails to mention is the motivation for this model. A branching model, as any other policy or technical solution, should be an answer to an existing problem. So decoupling the branching model from projects details makes no sense to me, although the article does a fair job describing the technical aspects.
I've been asked many times by units (big corporation) if this would be a good branching model for them when they are migrating to Git. I always tell them it's probably too complicated for their situation. Most of the units are trying to implement some form of Continuous Integration. Obfuscating that with complex branching models would only confuse them. Only when they encounter a real problem, that could be solved with this branching model, I suggest they try this out. I haven't still seen it happen.
However I must say, that the situation might be different in different types of projects. I've seen only these kind of CI-projects with a couple of hundreds developers with long lead times.
I've been asked many times by units (big corporation) if this would be a good branching model for them when they are migrating to Git. I always tell them it's probably too complicated for their situation. Most of the units are trying to implement some form of Continuous Integration. Obfuscating that with complex branching models would only confuse them. Only when they encounter a real problem, that could be solved with this branching model, I suggest they try this out. I haven't still seen it happen.
However I must say, that the situation might be different in different types of projects. I've seen only these kind of CI-projects with a couple of hundreds developers with long lead times.