In GitFlow, why not merge from master to feature?

Question

It seems to me that the sooner a developer merges with released code, the better. In the original GitFlow article this isn't done. The original picture is this:

When long lived feature branch on the far left is finally merged into develop, it is still based on version 0.1. Wouldn't it be better practice if the developers at least kept their branches up to date with master like this? Is there a good reason that GitFlow does not recommend (and implicitly recommends against) these "keeping up with the release" merges? (Additional merge commits in blue)

Answer 1

Working in a large enterprise codebase (my experience is with 20 fulltime devs), I feel the diagram misrepresents the amount of commits to master that occur relative to the commits to the feature branch.

When I develop a feature branch, I often see 200ish commits (non-squashed from 10-20 feature branches) pass by on the master branch. If I were to merge every time a new commit hit the master branch, I'd constantly be distracted from my actual work.

Secondly, are there merge conflicts to begin with? If there aren't, then it doesn't really matter. If there are, then it of course does; but I would prefer to focus on these conflict resolutions when my feature is fully developed (or at least hits a buildable milestone). It makes little sense to start merging conflict when my own work is still very much a broken WIP.
To that effect, it's perfectly reasonable to only merge from master when the feature branch hits specific completion milestones; which for an everyday feature branch may simply be the completion of the feature branch altogether.

Thirdly, I would advise against merging from master to feature when the feature branch originates from develop. In general it would be better to respect the order, and thus merge from master -> develop -> feature.

At best, merging directly from master, in the presented diagram, makes it the feature branch's responsibility to ensure the master commits get merged into the develop branch, which makes little sense.
At worst, it leads to multiple feature branch developers having to deal with merge conflicts (possibly in a different way) that then will again cause conflicts when these feature branches are merged into the develop branch.

Lastly, although this is tangential, tools like GitLab (and I presume others too) perform a check during a pull request whether it's possible to merge into the target branch with no conflicts. If so, preemptively merging from that target branch wasn't necessary. If not, developers are still able to then merge from that branch and resolve the conflicts in their own feature branch.