Not the answer I would have guessed, but:
In this particular case there is no impact.
Which seems like a bold statement for a leaked secret key, but in this one case I believe the warning about not leaking the secret key is more about best practices than actual concern. Since that is a rather unusual answer, I'd like to break down the things that would normally be a concern and explain why they aren't applicable here:
1. Circumventing the captcha verification
This is obviously a primary concern - if the leaked captcha secret key allows an attacker to circumvent the captcha protection, then you have a serious problem. However, the way the recaptcha flow works makes this impossible. Most importantly, the verification is done by sending the user's response to a google API (using the secret key) and checking for confirmation. Moreover, the response can only be checked once specifically to prevent replay attacks. This simply leaves no room for an attacker with a secret key to place themselves in the middle and fake a confirmation. It's really as simple as that.
2. Broad access credentials
In many cases a single key can be used to authenticate for multiple services. You could imagine a secret key that is used not just for recaptcha but also for other administrative tasks in the google cloud system. Leaking such a key would be very dangerous, as it would potentially have a nearly limitless impact.
As it turns out though, the keys for recaptcha seem to be limited only for use in the recaptcha system. Apparently this is a little bit isolated from other google services, and it doesn't appear possible to create a key that is used for anything other than recaptcha.
3. Use of paid services
If you pay for a service based on usage, then gaining access to the secret key effectively gives someone the ability to use the service and make you pay for it (although in this case you would also have to have a permissively configured public key). Of course this service is free, so that doesn't help anyone.
4. DoS through rate limiting
This one may be a concern, although I don't think so. Many free google services have rate limiting to prevent excessive usage, or to move you to a paid tier depending on your usage level. If the verification endpoint is rate limited than an attacker with your secret key could spam the endpoint fast enough to effectively DoS the key, preventing your service from verifying captchas. The impact that this has depends on how your service handles rejected verification attempts.
However, I don't see any mention of rate limits in the documentation. This doesn't necessarily mean there is no limit, but if there isn't a limit then this attack definitely isn't possible.
It's possible I missed something, but I believe that for a recaptcha secret key there is no actual impact due to a leak. I would still follow the suggestion and keep it secret. It's always best to practice best practices.