Exactly. But usually the biggest consumers of bandwidth are the ROPs, which is why you can get away with a slower ram + some type of on chip ram. Adding bandwidth makes sense not because xbone will have games that uses 270GB/s of asset data, but because if there is need the ROPs will have plenty of bandwidth to play with, while keeping the ddr3 free for assets and cpu.
Since the esram is fully addressable by the gpu this time, we might see it being used as a buffer for some interesting stuff like procedural synthesis... This could also be done without even touching the ddr3...
The 68gb/s ddr3 might sound like is terribly slow compared to 176, but compare the ratios of 360/Ps3 and Xbone/Ps4... You will see that xbone's ddr3 is actually not very much slower than 360's gddr3 compared to Ps3 ram setup... But that is something we should see soon enough: If the ddr3 is indeed slow we will probably see some games having reduced asset quality on xbone.
Really the biggest problem with ESRAM is just that it's tiny. Let's say I have several render passes - a few shadow map passes for the cascades maybe, a simple deferred pass, a resolve pass.
On the PC or PS4 I'd just fill in the command buffers and go. I'd have 2 places for sync points: after the shadow passes/the deferred render, and after the resolve. Once I've hit the second sync point, I just present.
On the the XB1 however, I need exclusive use of the ESRAM for my deferred pass, and I'd also like to have my shadow depth buffers in ESRAM during their passes, so I serialize them. First I do all my shadow passes, sync, then move them out and sync again.
Then I do my deferred pass and sync. At this point, I have to decide where I want to put all my buffers for post-processing/resolve pass. I want my final buffer to be there at least, and all the gbuffers I can fit after that. So I swap a buffer out for another, requiring a few more sync points, then do my resolve pass.
After the resolve's done my buffer is still in ESRAM. I don't want it locked there for a whole VSync interval, so I have to copy it out again before presentation. Already it's far more complicated than what I'd have to do on the PC/PS4, and each additional sync is potential time for CUs to sit idle and twiddle their thumbs. Imagine adding several post-processing passes to that.
And this scenario doesn't even take into account the idea of beginning to build the command buffer for the next frame while the GPU is till churning on this one. Just thinking about managing ESRAM contention in that scenario gives me a headache.