Yes, that’s the question. If we agree that it’s a good idea to treat directory junctions as directories, I’ll try to investigate if there’s a way how to do that; until then I’ll do nothing in this regard.
The golang issue you found I had seen too. It concerns the filepath.Walk method that has no protection against infinite recursion. It is a valid concern, and they resolved it by treating junctions the same way as symlinks, because that’s the “symlink side” of directory junctions that caused the problems. Actually, they had not many options to choose from. But that doesn’t mean that it is the same think. In other situations - and I believe this is the case of Syncthing too - the “mount side” of directory junctions is more important.
The answer you quote is completely correct. Technically, directory junctions are nothing more than symbolic links. Technically. It is written this way even in your quotation. But the “aforementioned differences in how they’re processed” are what distinguishes them from ordinary symlinks.
Use cases:
For instance, when I want to move a directory to another disk, e.g. because I’m running out of space on the original disk, I use a directory junction. (On Linux, you would mount the directory, in this case.) When I want to make a shortcut to another directory, e.g. logs on a server, I use a symlink.
When I want to backup a directory that contains a subdirectory redirected to another disk, I want to backup it completely, including the part stored on another disk. On the other hand, when I backup a directory containing symlinks, I do not want to backup the server logs to which they point.