The first one uses randomly generated CSRF tokens which uses a cryptographic strong random generator to generate the token.
This is ideal. In this case, the token is an absolutely unpredictable opaque block with no significance outside its intended context.
The second implementation I found uses HMAC which encrypts the session id with
secret key stored in the server side config.
This is simpler to implement. Presumably session IDs are already being generated, so nothing additional needs to be persisted. Since no further storage is necessary, it could be that this mechanism may be implementable in situations where a random token couldn't be worked in to a legacy design. This is a relatively elegant workaround. Assuming the secret key doesn't become known to the attacker, the token shouldn't be reproducible outside the server.
The third implentation I saw uses a combination of both, a secret key stored in the server side config is used to HMAC a random generated value
This is a little silly. Presumably driven by the fact that a an HMAC is a security-related concept, the author attempts to add security to his design by including something security-related. A sort of magic security talisman. Presumably it's no worse than using the random number alone, but it's certainly no better. Unless you count the warm fuzzy feeling you get from using HMAC in your security implementation.
It is, however, a reasonable work-around if you have a poor RNG, though in that case I would probably mix the session ID or something similar in there before hashing so that you're guaranteed that the number you hash in unique.