Symbolic links do take room, of course, but just the room it takes to store the name and target plus a few bytes for other metadata. The space taken by a symbolic link does not depend on the space taken by the target (after all, the target is not even required to exist).
Plain du reports the space taken by a directory tree on the disk. du -L reports the space that would be taken by a directory tree if all symbolic links were replaced by their target. The former is usually the useful information; for example, it's the space you'd recover if you deleted the tree, and it's (approximately) the space you need to back up the tree.
du on a directory tree shows (usually) a little more than the total of the file sizes. That's due to two things. First, du also counts directories, which take a little room to store file names and metadata. Second, du counts the disk space taken by a file, which can be different from the file size: the most common effect is that files take up an integer number of blocks (4kB on a typical Linux installation), so a 1-byte file can show as 4kB in du output; but compression (such as the primitive form provided by sparse files on just about every unix filesystem) can make the file size larger than its disk usage.
From the numbers you give, it appears that Thunar reports the sum of the sizes of the files in the directory tree, following symbolic links. It's actually saying so in a subtle way — it's claiming that the total size is 570.3 kB, not that the disk usage is 570.3 kB. What is not at all apparent from the user interface or documentation is that Thunar follows symbolic links when computing the size.
Which one is “right” is a subjective matter. du reports disk usage. Thunar reports total size following symbolic links. Creating a symbolic link has a negligible impact on disk usage, but by definition does change total-size-following-symbolic-links that Thunar reports.
Because the filename at the other end of the link is not (or might not be) the filename in the directory that you're accessing with ls.
Two problems with displaying the name of the target of the symbolic link in place of the name of the link itself:
The file does not exist. If the name of target of the symbolic link is displayed in the directory listing, you may be led to believe that this is the name of the file in that directory, but it isn't. The name of the target is not the name by which you access the file in that directory; the file with that filename does not exist (in that directory), or, in the worst case, it may be a totally different file (or a directory, or whatever) when accessed by that name.
Files may appear to have identical names. If the name of the target of the symbolic link is displayed, then you may find that it's exactly identical to another filename in that directory, which can not be true on a Unix system.
In these cases, it leads to confusion for the users, and they would have to verify the listing by using ls without -L, which would render the -L option pretty pointless.
This (not displaying the name of the target) is also the behaviour specified by POSIX, quite explicitly:
Evaluate the file information and file type for all symbolic links (whether named on the command line or encountered in a file hierarchy) to be those of the file referenced by the link, and not the link itself; however, ls shall write the name of the link itself and not the file referenced by the link. When -L is used with -l, write the contents of symbolic links in the long format (see the STDOUT section).
There is no further discussion about this in the Rationale section of the POSIX ls manual.
Best Answer
With
-L, it examines the properties of the file - contents or metadata, not those of the link. E.g. if you use-atime, it will check theatimeof the file, not the link:testdir/linkwas created aftertestdir/ref, but the file it points at was not.