The Austin Group ruled in:
http://austingroupbugs.net/view.php?id=1121

that the use of d_type shortcuts during nftw() has resulted in an unintentional regression in glibc: 

"Until glibc 2.3.6, in the io/ftw.c process_entry() code, we find:

  if (((data->flags & FTW_PHYS)
       ? LXSTAT (_STAT_VER, name, &st)
       : XSTAT (_STAT_VER, name, &st)) < 0)
    {
      if (errno != EACCES && errno != ENOENT)
        result = -1;
      else if (!(data->flags & FTW_PHYS)
               && LXSTAT (_STAT_VER, name, &st) == 0
               && S_ISLNK (st.st_mode))
        flag = FTW_SLN;
      else
        flag = FTW_NS;
    }

So, if FTW_PHYS was not set, use stat() on the path. If that fails (because of a dangling symlink, for example), then try lstat() on the path and check if the result is symlink; if so, emit FTW_SLN.

In glibc 2.4 (~2006) things changed to the situation we currently have. The change *appears* to be an unintended regression, since the associated changelog message make no mention of modifying the behavior of FTW_SLN.

So, I do think this is a glibc bug, not a fault in the standard, per se (though the standard could be a little clearer). 
"

As this regression is not standards compliant, glibc needs to perform an lstat (perhaps only when POSIXLY_CORRECT is set?) even when using d_type to shortcut the knowledge that a dangling symlink has been found.

See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1422736