ASVS v4.0.2-2.1.2 requires doing this as a "best practice" - https://github.com/OWASP/ASVS/blob/v4.0.2/4.0/en/0x11-V2-Authentication.md#v21-password-security-requirements
Verify that passwords 64 characters or longer are permitted but may be no longer than 128 characters
MW sets a limit of 4096
Not sure I see a rationale for limiting passwords on the top end... denying a DOS situation from new accounts making lots of long passwords? Preventing users from entering a password they never have a hope of remembering (well, maybe not, depends on if 'character' means Unicode codepoint or ASCII character)? (No-one will realistically enter a long password without the use of a password holder, so maybeeee it doesn't matter.)
The MediaWiki limit was set to 4096 in T64685: Extremely large passwords as DoS, as adequate to prevent denial-of-service attacks against pbkdf2, which is the MediaWiki default hashing function according to https://www.mediawiki.org/wiki/Manual:$wgPasswordDefault. However, other hashing fuctions (namely argon2) are available that have different performance characteristics, so 4096 may not be adequate in those cases. pbkdf2 is currently in use on Wikimedia sites (rOMWC wmf-config/CommonSettings.php:577).
There isn't really a specific rationale for using 128 vs 4096 as the upper limit for passwords. They're both longer than what is currently necessary to prevent a brute-force attempt and small enough to prevent DOS issues. OWASP added the maximum upper limit requirement in https://github.com/OWASP/ASVS/issues/756, and the choice of 128 was fairly arbitrary.
As both 128 and 4096-byte passwords are absurdly long, the user-facing impact of this change would be minimal. The MaximalPasswordLength password policy currently only suggests a change on login, so users currently using longer passwords could continue to do so (while being nagged on every login).
If the maximum password length is left unchanged, it should be re-evaluated if the password hashing function is changed (T216682).