Apparently, the software permits developers to provide their own session IDs, which (because people are often bad at security) might be short and/or predictable. The signature is thus added to create a minimum amount of entropy in the token to prevent guessing or brute-forcing another user's token if the token itself is low-entropy.
Or, as you put it, the odds [against] guessing somebody else's session ID should be astronomical... but you probably generate session IDs using something like "16 bytes from a CSPRNG" and some people instead use
Random.nextInt() or even just an incrementing counter or something. In those situations, guessing or even brute-forcing other IDs is pretty easy, so the token is signed as, essentially, a way to "mix in" the entropy of the secret with the (possibly low) entropy of the token without revealing the secret itself.
Obviously, if both the token and the secret itself are guessable and the attacker realizes this, this will still be insecure. But, at some level, there's nothing you can do about a dev who is obstinate about being insecure. No matter how many footguns you take away, somebody will nail themselves to the floor with a pencil.