No, you are wrong - that's not how Duke Nukem 3D's mirrors worked at all.
DN3D used a portal engine. A joint between any two sectors was arbitrary to an extent, and when the rendering engine came to a portal, it knew that it has to start rendering another sector in that. The sector behind the mirror was basically a place holder to deal with a quirk in the engine - the only point of the sector was to be bigger than whatever you needed "reflected". It didn't contain any real geometry. In fact, it worked pretty much the same way "portals" work in Portal - except that Portal (itself being based on a portal engine) creates the portals at runtime, and has a limit to how many times the portals can recurse (i.e. A -> B -> A -> B -> A ...), while Build (DN3D) would simply crash as its stack overflowed if you pointed a mirror at another mirror.
It's obvious how simple it is to implement a mirror with that - make a portal that points back into the room. This meant that rendering the mirror would cost exactly as much as rendering the room itself, giving great performance and consistency. As long as you didn't point a mirror at another mirror, that is. If you look through the Build engine source code, you'll see
there's no code handling mirrors at all - there doesn't have to be one, because that's how portals work NOTE: actually, there is code to flip the rendered pixels - it just doesn't flip the geometry and all the various sprites and effects. The editor had to be able to make these "fake" portals, though - looking back on itself. If you want to know more about the quite smart Build engine, there's a great analysis by Fabien Sanglard at Build engine internals. The whole engine has been open sourced and ported to modern platforms as well, though the old one still works flawlessly on Windows 10 (tested for you :P). Many of the games based on Build have also been open sourced and/or remade.
Why is this no longer used? Well, some engines no longer prefer portals, for one. It's tricky to apply a lot of graphics hacks and optimizations - I can't point you to anything specific, but a lot of post-processing depends on hacks that wouldn't work in a true portal engine (they make a lot of assumptions that no longer hold). This is basically the same kind of issue these games have with stereoscopic imagery - the hacks no longer work.
Most importantly, mirrors got more complicated. They can have complex shapes, textures, they may be on the ground (also known as "water") etc. While all of those problems are solvable in a portal engine, RTT becomes the simpler choice at some point, and GPUs are fast enough to handle it.
However, even with all that, there are plenty of games with hardware 3D acceleration that do things "real". Of the older games, Quake 3 or Alien vs. Predator, for example. As far as I know, Source engine games still use "real" mirrors. If you expect that people are going to get close to the mirror, and you can guarantee that there's not too many reflective surfaces at the same time (e.g. through level design), portal mirrors are still very attractive.