For most of the reason codes, no special behavior applies (the certificate is simply revoked). An exception is the keyCompromise reason code: If a subscriber revokes a certificate using that reason code and demonstrates control over the private key, the entire key will be blocked and all other certificates using the same public key will be revoked as well (see this incident for more information).
The reason code provided by the subscriber will be used in the OCSP and CRL data structures provided by Let's Encrypt. This means that your reason code is publicly announced to the world. Someone who checks the revoked certificates status will see it. Selecting an appropriate reason helps clients to better understand the reason behind the revocation (which is potentially helpful for determining severity). This is not in Let's Encrypts hands though: The certificate is revoked in the same way in all cases (except keyCompromise).
Let's Encrypt is required to adhere to the Baseline Requirements, which as of last year mandate certificate authorities (like Let's Encrypt) to document the available reason codes, to specify their applicable usages and encourage their usage. Let's Encrypts emphasis on the definition fulfills this requirement.
In that case the reason code will be implicitly "unspecified", which means the CRL and OCSP revocation reason codes will be empty/absent. The certificate is revoked, but its key is not blocked. Entities consuming CRL/OCSP will not have further information about why the certificate was revoked. Otherwise, nothing happens.