The ARB has provided more reason why fixing the problems with buffer objects requires we need immutable buffer storage.
glTextureView requires an immutable texture. It doesn't work without immutable textures. It takes immutable textures and creates immutable textures.
Why? Because the API would not be possible otherwise.
If you can change the storage of the source texture, how does the view change? What happens if you modify the texture's storage such that the view's relative mipmap pyramid is invalid?
glTextureView is basically impossible without immutable textures. You couldn't do it, because important aspects of view textures could be changed by altering another texture. Oh, you could specify that views become incomplete if you do that or whatever, but the API would ultimately be far too fragile.
Something similar is true of buffer objects. If you want to have binding contracts for buffer object usage (rather than hints), if you want explicit requirements on use patterns that the API would throw errors when you violate, then you need some guarantees about buffer object storage. You need to know that someone can't just re-specify it at a whim. And there are only two ways to do that: 1) create a new object type, which requires lots of API additions, or 2) do what they did with textures and effectively create a new object type within the old API, which can have different behavior attached.
Immutable textures are a way of creating a new texture object without the API issues of creating a new texture object. Immutable textures have different properties and different APIs work on them. Similarly, immutable buffer objects could be used to create a new buffer object without the API issues of creating a new buffer.