I wouldn't characterise it as "backlash". Just disagreement.
As we frequently say around here, protocols are not just bags of syntax - they have semantic meaning. Hashable primarily exists to support user-defined types in hashed collections. It's the very first sentence of the documentation:
You can use any type that conforms to the
Hashableprotocol in a set or as a dictionary key.
Equatable is part of the essential semantics for such usage, that is why it is part of the type. It is not, and does not claim to be, the only way to produce digests of custom data. For instance, as I mentioned previously, it does not support custom hashing algorithms, so it can't be used for a high-quality bloom filter in the first place. You would need your own protocol for that, and you are more than welcome to create one.
It is not uncommon that consumers of protocols only need some part of what it offers. As an example, @taylorswift has just posted a thread where they wish for a more limited version of RangeReplaceableCollection which only supported appending (AppendableCollection). Ultimately, protocols are the units of useful abstraction for generic code, where "useful" has to be judged in the context of particular use-cases the authors intend to support.
(as it happens, RRC does have some design flaws in that regard; it is not a particularly useful unit of abstraction due to its lack of ability to maintain positional information across mutations, but that's a separate topic).
It would not be practical to make every function its own protocol, and even if we did so, it would not necessarily allow for more powerful generic abstractions - as more important than the function or type names are the semantics each protocol encapsulates. Hashable types support hashing using a single algorithm only, and require Equatable, as that it what is required to support Dictionary keys and Set elements. That is part of its semantics.