The problem isn’t with the WordPress object cache, as far as I know it’s not persistent across requests. The problem happens with sites that have some kind of persistent caching: https://developer.wordpress.org/reference/classes/wp_object_cache/#persistent-caching. This can be configured through a plugin, but it’s also enabled by default by some hosting providers, for example WP Engine. I think for the case of WP Engine, they don’t enable the object cache on their login page, but they do enable it for anonymous users on all other pages. So on WP Engine the problem is only triggered if the “login with Discourse” link is added to a page other than the login page.
The problem with the discourse_sso_url is that when it’s always set to the same value, for sites that have a persistent cache enabled, it will always return the same nonce. Setting its discourse_sso value to a random string, instead of setting it to its default value of 1 breaks the cache. At least it’s always worked that way when I’ve tested it previously. I don’t have things configured to test it at the moment.
Edit: there are a few more details about the issue here: Discourse (as provider) + WP SSO nonce error - #14 by simon. It’s quite a while since I looked at this. The fix for the issue at the time seemed to be to both add a random string to the discourse_sso_url and to ensure that page caching wasn’t enabled on the page the login link was displayed on (otherwise, the random string won’t be unique for each visit by an anonymous user.)