This pushback against mapped buffers isn't good. It's not good because mapped buffers aren't going away.
In ES 3.0 the following functionality is offered for mapBufferRange:
copy read buffers
copy write buffers
element array buffers
pixel pack buffers
pixel unpack buffers
transform feedback buffers
ES 3.1 adds the following new functionality to mapBufferRange:
atomic counter buffer
dispatch indirect buffer
draw indirect buffer
shader storage buffer
GL 4.0 adds the following new functionality to mapBufferRange:
bufferStorage (and its associated flags which also add new)
And that was just mapBufferRange, mapBuffer itself is also expanded. In fact most options for dealing with and structuring memory transfer behavior are not contained in the buffer[Sub]Data calls, they've all migrated to the variety of buffer handling/mapping routines.
Nobody knows what Vulkan will bring, but I'm fairly certain mapping buffers is going to be part of it.
It's of no practical use to ignore this feature. It's a problem that needs to be solved (and solved efficiently and as closely resembling the underlying APIs behavior) as possible. If you don't solve it now, you'll have this exact same debate again for WebGL 2.1, WebGL 3.0, WebVulkan 1.0, WebVulkan 2.0 and so forth. Except that by the time that it got trough to this standards body that mapped buffers aren't going anywhere, it'll come in a zillion colorful fashions of options and it will be very, very hard to implement as a first throw.