This does not appear to be a table of contents that Scrivener would create. For one thing it places the ToC into a file named ‘contents.xhtml’, but yours is coming from ‘body2.xhtml’. But the structure is all wrong as well. A real nav ToC line would look like:
<li><a href="body7.xhtml">Alles was du brauchst, ist weniger</a></li>
I’m wondering if maybe you have created a custom contents page, but its name does not match the ToC settings in the compiler tab for setting up contents? The default may be the English word “Contents”, which could be a factor here. You can change that to what you want to really call the section in the binder (and in ePub navigation). Not doing so would indeed treat the contents as a normal numbered ‘bodyX.xhtml’ section like you get. It wouldn’t be analysed as a navigation element, and thus wouldn’t establish the ebook’s internal navigation—it would only be a section with a list of links in it.
So that’s one problem, the other appears to be excessive formatting. The custom ToC section for ePub is not like normal content, it has strict rules that are described in the user manual PDF, under §22.3, Contents in Ebooks. Flip to the yellow tip box for the instructions to follow.
This is because, as noted, this is not only something your readers will see when flipping through pages, but it is metadata that defines how the book works—how the software reader will create a navigation menu, and how the next/prev chapter buttons or shortcuts work.
So you can’t have styled text in here (you seem to be using a “Standard Links” style), nor additional elements on the line. It must be purely a hyperlink to the section, from the very first character on the line to the very last. No bullets, no annotations, nothing fancy.
The last component that confuses me is how you are getting an <a id="..."></a> element in the output. I cannot think of a feature that would cause Scrivener to create something like that. It will insert section IDs, but it tries to embed them into the nearest block element rather than using a void anchor like that, and it uses generic labels to avoid validity problems like how titles might have bad characters (the comma in this case) for IDs. For example we might expect to see, <p class="standard-links" id="doc2">...</p>.