The PKCE spec defines two methods, S256 and plain, the former is used in this example and is the only one supported by Auth0 since the latter is discouraged.
Why did they design it so plain was even a valid value to use?
If you use plain, then if the auth code is stolen, the code_verifier can also be stolen since it's the same value as the code_challenge.
I don't see how this adds any security at all.
It is not so much for backwards compatibility as both were standardised at the same time, in the same spec, though granted some early adopter deployments of "plain" may have existed at the time.
It is mostly there to accommodate for constrained environments that have no way of generating a SHA256 hash because the capability simply does not exist on the platform because/or is too expensive to load/run. Remember that a regular OAuth/OIDC client can run without performing any cryptographic operation itself, it would be cumbersome to force usage of crypto for all forms of PKCE.
Plain PKCE without SHA was designed to improve the security on mobile (thus public) clients where a malicious co-installed app could try and intercept the authorization response to steal the authorization code. It would be able to exchange that code at the token endpoint using only publicly known static parameters when PKCE is not used. When applying (even plain) PCKE, the malicious app would also have to steal/intercept the outgoing authorization request to get access to the code_challenge/code_verifier that is dynamically generated for each authorization request.
Intercepting authentication responses and requests require different techniques. The former was deemed relatively easy for attackers by registering a handler for the URL scheme of the redirect URI replacing/on-top-of the one from the legit app. Intercepting an outgoing request may be more complicated. Anyway, combining 2 different attack techniques is arguably more difficult than one, which is why plain PKCE is considered to be still useful for some cases.