From what I can see, it should be good enough to just use the same session id which is stored in the cookie as the CSRF token. If an attacker has your session id, then CSRF is the least of your problems. I don't know why people come up with more complicated schemes... Am I wrong?

Yeah, you can. There's a couple of reasons you might not want to but there's nothing seriously wrong with doing that.

There's a good explanation here: http://stackoverflow.com/a/25475141/240921

That would make tokens valid across different applications that share a session. A compromise of one application would then jeopardize all your applications.

Just reduces the risk surface a bit.

A compromise of any session ID is more serious than losing the CSRF token anyway. Once I have your session ID I am you from the POV of the server, so who cares about the CSRF token?

Also, you may well have different session IDs across different applications anyway - pretty good idea, if you want to be able to selectively deauthorise logins.

The problem with that is that, if you steal the CSRF token (which is easier to do than a session ID hidden in a cookie), it's game over.