I think there's a significant difference between "little helper" and "the monomorphic function that is used to implement `pure`" - with a slightly different framing, we might be able to come to an agreement that both the monomorphic an polymorphic versions of this function are useful in different contexts.
https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Base.html#line-972We define a monomorphic function for this operation, we just hide it in the implementation of the typeclass instance; we do this frequently, intentionally making a monomorphic function inaccessible to the user unless it's called in a polymorphic context (and, if they want to intentionally monomorphise it, require using an extension - type applications - which is particularly ugly/inconvenient for operators like `>>=`.) I think this is unfortunate as a general design choice; the user of a library should have the flexibility to choose, not be forced into one or the other. For [] we have the robot monkey operator, and this is an idiom that people can become familiar with - but it does not appear natively in any documentation; it is a partially applied constructor rather than a top-level function.
My guiding principle for API design is that one should always expose the fundamental building blocks as a low-level API, and then provide a smaller interface for the common use cases. Typeclass instances are no different - they are the general interface that allows us to invoke what is ultimately a monomorphic, low-level building block function in a polymorphic context.