I believe that the reason that t.ValidationError isn't considered readonly is due to its Context type, which is interface Context extends ReadonlyArray<ContextEntry> {}.
Due to limitations in the compiler API, it's not easy to detect an interface that extends the base array types.

If they had instead used type Context = ReadonlyArray<ContextEntry>, then it would work fine.

I don't think it's unreasonable to add an option to ignore functions in a callback position.

I'm not sure how much api is available for this but something like the following would solve most common use cases I think.

// Just an alias to the original type
/**
 * Explicitly mark a type T as allowed for `prefer-readonly-parameter-types`
 * ⚠ `Only use it when you know what you're doing` <- Or some similar warning text
 */
declare type Mutable<T = unknown> = T;

      '@typescript-eslint/prefer-readonly-parameter-types':
        - error
        # Either
        - allowedTypes: ['Mutable<*>'] # Regex/Glob pattern to exclude
        # Or
        - allowedTypes: ['./global.d.ts#Mutable'] # Full path to the type itself relative to the config file
        # Or
        - allowedTypes: ['io-ts', 'package-name', 'package-name/specific/type/import/path'] # Package name or path to package specific type as it would be if it was imported
        # Or
        - allowThirdParty: true # Any type that is not declared within the tsconfig project src/root being linted

import t from io-ts;

// No errors here
const parseValidationError = (error: Mutable<t.ValidationError>) => {
  return error;
}

// Or here
const parseValidationError = (error: t.ValidationError) => {
  return error;
}

The above Mutable approach is not really any different than an eslint-ignore comment all over the place and it might not even work given that the actual resolved type is the same as the original however it might be useful as a regex/pattern based allow list. The package-name approach would allow for a granular control while allowThirdParty would be en escape hatch and probably most widely used if implemented.

I don't think it's unreasonable to add an option to ignore functions in a callback position.

+1 For that as well

I'm setting up a project and... this is indeed painful. So much so that I'm likely to disable it and accept mutation risks that I'd like to avoid. The discussion here is interesting, but...

I don't think it's unreasonable to add an option to ignore functions in a callback position.

I'm not sure this is the best solution. What I would want is:

• If a parameter's type is inferred, the definition that supplies that inference should be the place the linter checks (and if it's out of scope, it should not result in an error).
• If an inferred parameter is mutable, the linter should treat it as readonly anyway, for purposes of in-scope mutation, assignment to a mutable type, or passing as a mutable parameter to another function.

Given the prevalence of mutable types even in libraries that strongly focus on pure functional patterns (the io-ts library which produced this error for the OP being one of them), I don't really see how this rule can be usable without those changes (or something like them).

There's always the option to contribute fixes upstream?
If the types are mutable when they really shouldn't be - a PR to the source of the types can fix that for everyone, even those that don't use this rule.

Happy to accept a PR to add a new option to ignore parameters without an explicit type annotation.

As with almost everything in this project - this rule is maintained by the community. The best and fastest way to see a change done is to roll up your sleeve and contribute!

This is a pointer to roughly where you'd need to start making a change:

@bradzacher thanks! I'll take a look and see if I can make some progress on the change, I'd be happy to contribute.

At this state I would call it fixed by #2668 since it seems the only agreement reached is to "ignore parameters without an explicit type annotation", which ignoreInferredTypes does. If anyone has anything else they want to see, please open a new issue.