are you suggesting that using a ParameterMessageInterpolator when no EL implementation is available is not a valid use case?

It is a valid (as in "useful") configuration if you don't have any constraint messages containing EL terms. E.g. the default message of @DecimalMax contains EL terms, so using the parameter interpolator isn't really useful for that. That's where I'm having some doubts about choosing an interpolator automatically for the user. If they require EL as per the constraint messages they use but there is no EL implementation present, wouldn't they more benefit if you were to warn them early on instead of giving them the parameter interpolator?

If an application is using EL-dependent annotations with an ParameterMessageInterpolator, I'd argue that it's probably user error,

I would agree if the application developer actually had chosen the parameter interpolator themselves, but it seems you are making that choice for them based on the dependencies available? I'm a bit concerned that it's asking the user very much to understand that they must not use specific constraints (which happen to use EL by default) when starting with specific Spring Boot starter POMs (not sure whether I'm using the correct term) that don't include EL.

but the outcome of that (processing uninterpolated messages or failing hard?) is probably hibernate's choice.

The outcome is mandated by the BV spec: failures during message interpolation must not cause exceptions. Hence the only thing we can do when seeing a constraint needing EL but no EL is present, is to let the message go uninterpolated.