I had never heard of this distinction, however it immediately made sense to me because I've run into this case in Ruby where using a ruby "delegate" object actually was much more verbose than I had envisioned because of all the context I had to bring over to the delegate object one way or another. In the event I decided "delegation" was not right because the implementation necessarily violated the Law of Demeter.
So yeah I think pragmatically it does matter.
In this case a distinction is being drawn that would make "delegation" mean something that is worse from the point of view of good software design, which would leave the thing that is better software design without its commonly understood name. Doing this would create negative value.
That says that delegation as defined by GoF does more to promote modularity than the original definition, and therefore is more often going to be preferred in good software design over that defined by the article.
This is not to say that there aren't cases where what the article promotes is not convenient. Violating modularity is usually convenient. But that is a convenience that we should always be wary of.
I think we've failed then since we've totally overloaded and confused basic concepts such as weak/strong typing and dynamic/static typing.
To make matters worse, those are cases where we as programmers invented to terminology at hand and didn't just appropriate it into a programming context.
This whole "object-orientation" bent in the Ruby community lately just feels like a crusade, with people thumping on old OO books, each proclaiming theirs is the "true way". And, usually, like in this example, it doesn't even matter because their code ends up doing exactly the same thing with little real-world gains in readability or ease of understanding.