You're right. Unless the software is doing something very peculiar, which should be very apparent when reading the code and documentation, and I can't imagine what it could be, the salt generation and the application of PBKDF2 are unnecessary.
If you have 32 bytes from a cryptographically secure random generator, you can use these 32 bytes as an AES-256 key. A CSRNG is as good as it gets: it's uniformly random and non-guessable.
You would use a (“plain”, non-stretching) key derivation to obtain a key deterministically from some inputs which are not necessarily uniformly random, but have sufficient entropy. A typical case that requires a key derivation step is the output of a Diffie-Hellman key exchange algorithm: it needs to be deterministic so that both parties calculate the same secret key, and you can't use the output of the DH computation directly because it's a number with some mathematical properties and so it isn't uniformly distributed. Another case that requires key derivation is when you have some secret material of limited length (but enough so that it can't be found by brute force: at least 128 bits), and you want to construct multiple keys whose total length is more than the secret material.
A CSRNG takes an entropy source as input and applies a pseudorandom computation (CSPRNG: cryptographically secure pseudo-random number generator) to produce random output. A key derivation function (KDF) takes input and applies a pseudorandom computation to produce pseudorandom output. A CSPRNG and a key derivation function have fairly similar security properties: as long as the adversary doesn't see the secret input, even if the adversary sees part of the output, they can't figure out anything about the part of the output that wasn't given to them. It wouldn't make sense to just chain them. It can make sense to chain them in combination with some third thing, for example using a CSRNG to generate a public salt and a KDF to combine this public salt with a secret key to generate another secret key, or using a KDF to generate a seed for a CSRNG which then gets used by a subsystem that doesn't have access to the original KDF anymore.
A stretching key derivation function (such as PBKDF2) is useful when the input has low entropy. “Low entropy” means that the input is plausibly guessable through brute force. A CSRNG output has maximal entropy for its length, and 128 bits (16 bytes) is enough to put it well outside the realm of brute force guesses. (Quantum cryptanalysis might raise the bar to 256 bits in the future.) Key stretching is used for secrets that are short enough to be memorable, typically passwords or passphrases. The only reason why you'd need to apply key stretching to the output of a CSRNG is if this output was deliberately kept short to be memorized as a password (presumably in a form encoded suitably for humans, such as a string of printable characters or a list of words).
Taking 64 bytes from a CSRNG and passing them through PBKDF2 doesn't make any sense. Just use the CSRNG output as a key. The use of PBKDF2 isn't a direct security risk, but it hurts performance and it increases the attack surface. Beware that if the current software does this, it indicates that the authors didn't understand what they were doing and there may be other problems that are actually security flaws.
