True, but perhaps it's too strict to require both memoryview and the represented object to be immutable?

The logic is as follows: 

Every object in Python can be seen as a view of some outside data (in memory, on disk etc.). And while Python's runtime may attempt to guarantee immutability of its objects, it cannot guarantee immutability of the outside data. Therefore a hashable object is an object immutable from the perspective of Python's runtime.
Memory views connect Python objects with outside data. They can be marked as immutable by Python's runtime. Therefore it should be sufficient to be hashable regardless of volatility of outside data.

In your example the immutability of the ndarray is indeed bypassed via a view created beforehand. But that's implementation detail and may actually be a flaw (i.e. being unable to propagate the change). The documentation [1] somewhat warns your that this behavior might change:

> However, **currently**, locking a base object does not lock any views that already reference it, so under that circumstance it is possible to alter the contents of a locked array via a previously created writeable view onto it.

1: https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.ndarray.flags.html