The depth and stencil buffers are single buffered, that is why in both the double and triple buffered situations there is only one 32bpp. In practice this is also true. Indeed:
- A compositor does not use the depth/stencil buffers of an application. In fact, it does not even have access to those buffers.
- GL ES2 does NOT support read back of stencil and depth buffers
So in practice, only the color buffer is doubled (or tripled or whatever). The key point here being that the stencil and depth buffers are "private" data of an application, where as double or triple (or whatever) buffering is about what to render to so that a compositor (or a more low level part) can present it.
As a side note, if one really needs read back from the stencil and depth buffers of the previous and current frame separately, triple buffering _only_ happens on the color buffer, so the relative added memory is even lower as a percentage. The idea behind triple buffering the color buffer is so that neither the compositor or the application has to ever wait: the application chooses whichever buffer is "not the last one rendered to and not the buffer the compositor is presenting" and the compositor always presents the last buffer finished. Only locks are for updating those pointers/integers.