I think there's a strong argument to be made for NEVER having an expiration on owner-only tokens, btw. Since the user and the developer are the same person, they have a lot of other ways of disabling use of the token, such as disabling the key, or... just not running their code.

The code could be ran by someone else. The token basically acts like a password; if the password is stolen, there must be a way to invalidate it. Disabling the key works, as long as whatever system consumes the token does check whether the key is valid. But the parent task talks about "APIs implemented in NodeJS or another system, which depend on the JavaScript Web Token (JWT) data to tell if a token is expired"; it doesn't make a lot of sense for such a system to not check with MediaWiki whether the token has been revoked, but do check whether the key has been disabled, so I assume it would do neither and just rely on the token as a cryptographic proof of authorization. In that case, infinite expiry does raise the exact same problem for owner-only tokens.

(Also, even if disabling the key would work, the developer would need to understand that that needs to be done and merely resetting the access token is not enough, which is not the case with the current UI.)