The thing with games today is that there are several different steps that need to be done for a frame to be rendered. The CPU needs to run the game logic and send triangles to the videocard, the GPU needs to transform, light, and raterize the triangles. Any of those things can be a bottleneck for your specific game, and the one that is the bottleneck will determine how fast your entire game runs. The games speed is "bound" by that part of the execution, so you can be CPU bound (your game logic or the time spent in directx or the videocard driver is what's limiting the speed) or transform bound (the number of transformations of vertices being done on the GPU is what's slowing things down) or fill bound (the rasterization of triangles is the bottleneck) to name a few.
When rendering a big mesh, like your example pyramid, several things can potentially be the limiting factor. For example, if you sent each triangle individually, with one DrawPrimitive call for each, you would quickly become CPU bound; you would spend more time in DirectX and the driver than actually rendering stuff. If there's loads of polygons, you might get transform bound, because of all the vertices that the GPU would have to deal with, especially on older cards.
My point is, that IF you are transform bound, your pyramid with millions of polys would cause a problem, and you could solve that by reducing the number of polys, cut it up to make better use of your octree, or using LODs). But if you're not transform bound, then it won't affect your framerate any more than rendering just one polygon. Because if you're not transform bound, but say CPU bound for example, it means that the transformation part of the pipeline is always waiting for more stuff to do, so throwing more triangles on it, without increasing the number of draw calls (each draw call uses up CPU power), will not affect framerate at all. It will just mean making better use of the available GPU power.