I'm going to offer a contrary opinion here and say that while the work is technically impressive, it's also crap. It's purely a case of "if the only tool you have is a hammer, everything looks like a nail". It is also NOT just HTML and CSS. Most of the real work is done in JavaScript. Given that, you might get better performance writing a software rasterizer that puts the whole image into a single rectangle and put that on a single div without 3d transforms. Another more "pure" implementation would use XSLT to convert XML into SVG with 3d transforms along the way.
What we really see here is a JavaScript 3D engine with a CSS backend. Impressive - yes. A good idea - not so much.
Well...sure. The correct answer is "use WebGL, it's designed for this." Looks like the guy learned a lot about 3D engines though. His next goal (to make a CSS output for Three.js) is similarly silly, but the history of computing is full of ridiculous side projects.
I think you might be misunderstanding why this was made, it wasn't made to be a good idea or even an actual engine that people use. The person made it because they could, because it's fun to do neat stuff for no other reason that to just do them.
"Given that, you might get better performance writing a software rasterizer that puts the whole image into a single rectangle and put that on a single div without 3d transforms."
Is it slow for you? It's totally smooth for me, rendering full screen on a big retina display. I not sure I can imagine there's any way you could write a software renderer in JS to do that.
I found it to be horribly slow and really weird in Firefox (sometimes see-through walls, z-sorting somehow flipping with barrels behind columns being drawn in front).
In Chrome, though, it's buttery-smooth with only small glitching.
Still, both are glitchy. I'm glad I went with THREE.js and not CSS 3D transforms for my latest 3D web project. THREE.js just works.
What we really see here is a JavaScript 3D engine with a CSS backend. Impressive - yes. A good idea - not so much.