Poser and DS use different cloth sims, where the one in Poser is, like you said, from 20 years ago. DS has a more modern one, and they have named it "d-force". Poser has no name for it, so it's just generic "cloth sim". Same thing for rigging - in Poser it's just generic "rigging", while DAZ has named it "TriAx", even if it's the same thing Poser uses. I believe giving things fancy names is the way DAZ advertises DS features, while Poser has traditionally avoided any kind of hype about anything it does - which is why so many users only know a very small portion of what Poser can do.
As for DQS, you are basically telling me it's TriAx with DQ for calculating rotations, where TriAx is the actual rigging method, and DQ is how rotations are calculated. Personally, I rather keep those things separated, since TriAx can be used with either Euler or DQ rotations - it doesn't care how we calculate joint rotations. For instance, Poser uses TriAx with Euler rotations, while DS does the same with DQs. In either cases, it's still TriAx rigging under the hood.
The "dual" in DQs comes from the necessity of using 2 sets of quaternions to be able to make 3D rotations. The reason is that a single quat can only provide 4D rotations, for which we have no practical use. Sometimes people omit the "dual", but if you are getting 3D rotations from it, you can be sure it's a dual quat. Poser supports both Euler and DQs. Like mentioned above, I have used it in my scripts, and the "Game Dev" Poser version (Poser 10) used DQs on their Kinect mocap support. For the record, dual quaternions (also known as "Euler Parameters") were around since the mid 19th century, so this is not something new. DQs are just more used nowadays because computers can calculate them fast enough to be useful. It's a similar thing with fractal graphics, which we can find painted on vases from ancient Greece, but only became more popular nowadays because computers have become fast enough to calculate them quickly.
To the best of my knowledge, DQs can only calculate rotations, which is a peculiar property of Complex numbers DQs are based on. There is no challenge in calculating translations, since plain old linear algebra can handle it. Mathematicians have spent a great amount of time trying to resolve rotation gimbal locks, which is why DQs were conceived. If you look at the 4D math used in DQs, it's actually crazy complicated even to understand it, since we cannot visualize 4D space in our 3D world. It would make no sense to use that to calculate things like translations, which can be easily solved with linear algebra.
If you want to calculate both translation and rotations, better use matrices, since those provide both - but are affected by gimbal locks. Matrices only support Euler rotations, so we have to choose. There are ways to convert from matrices to DQs, and vice-versa. But if you opt for DQs, translations have to be calculated separately, which is how I did in my "Scatter Tool" script for Poser. Neither methods are faster or slower - the difference is on handling gimbal locks (or not).
As for your question, both SimpleBone and TriAx can use JCMs, but not bulge maps, since that would require extra maps, and only TriAx can have those. In general, ERCs are independent from the rigging method, so I believe any rigging system can use them. SimpleBone used in Genesis 3/8 can use ERCs to make up for the lack of bulge maps, which make these figures heavy on pose correction morphs.
For the other questions, DS supports legacy (spheres-based), TriAx, and SimpleBone rigging systems. Poser supports them all as well, but SimpleBone tends to be reserved only for exporting assets to game engines. It would make no sense to downgrade the rigging quality if it's going to be used in Poser itself. Loose clothing is hard to rig, no matter what rigging system Poser or DS offers. The way all of these rigging systems were designed was to conform tight outfits. There is no easy way around this.
Indeed, Dawn and Dawn2 use TriAx, which is the best out of the alternatives we have in Poser/DS. Although the way TriAx works in Poser and DS is basically identical, DS uses a different coordinates system and scale, plus the way the weight maps were implemented is incompatible with Poser. That might be a consequence of DS being unimesh internally, while Poser is not. Poser is soon to receive a unimesh version, so the rigging might change somehow, but that is an internal change - perhaps not something users would notice. That might make Poser even more incompatible with DS, but that was to be expected when we look at how things have progressed so far.