All I am going to say to this, is that you are making many assumptions here that simply are not true. And they have been pointed out to you in the past.

Saying that a dog has five legs and no tail doesn't make it true.

These not assumptions, they are the results of my experimentation.  How else am I supposed to find out how things work in DS 4.8?  It isn't like there is complete, current and accurate documentation, now is there?  Find someone to help you should never be part of ANY end user documentation.  And yes,  that italicized phrase is actually in DAZ's documentation. 

Say what you like - should I believe you or my lying eyes?  I believe in the scientific method, even if you don't.

DSON most certainly does cause issues with Poser.  2 fully clothed genesis 2 figures & I am saving every five minutes, because either the dials will stop responding to user input or it pukes completely - remove the need for DSON & the problem goes away.  The variables that changed was turning off DSON and using a genesis figure exported from DS  via File > Export.  I understand that crashing applications is a way of life on the Windows platform, so perhaps you don't even recognize it as a problem - I am running OSX (and before that OS/2, since 1992), so I am simply not as tolerant to misbehaving software as windows users. 

Every .duf files does go through the DSON subsystem - the fake Poser file (.cr2, .mc6, etc). calls a python script (the .py file - this 2 line script is the same in every PCF, only the name is changed), which in turn starts the DSON subsystem (to access the .duf file).

Performance does drop when you move to that second fully clothed figure.    So far, from what I have seen, (again, based on USING the product), I have narrowed it down to 2 possible issues:

1.  32-bit issue, which may mean that it is out of both DAZ & SMs ability to fix.   The idea of rewriting the entire PoserPython subsystem of solid, working code to deal with a few folks that want to use an interpreted scripting language to handle data sets of more than 2Gb isn't very appealing.  And that isn't just SM, most of the python community is still on the Python 2 branch and don't see any reason to move off it.  And even if SM did move to Python 3 branch (currently at 3.4), it isn't like DAZ would actually go and recode DSON, since that is now depreciated software - fixing code isn't exactly their strong suit, based on my experience with DAZ software over the past 11 years or so (Yes, I own Bryce, Cararra, and Hexagon, as well as DS4.8).  One also has to take into account that in the DS/Poserverse, too many users are still running 32-bit systems.  (Note to folks still running a 32-bit system: Get a real computer - you are holding both SM and DAZ back.  If you can't afford a 64-bit computer in 2015, you probably can't afford to purchase content either.)

2.  OSX issue - the DAZ "programmers" are not very familiar with OSX - everything appears to be built in Windows and ported to OSX - the single platform emphasis has other long-term implications for DAZ.  Moving to iray as the default render system for DS will be driving off everyone that doesn't use Nvidia cards - which will be most of the OSX users and windows users that have an AMD card.  Most people aren't going to drop money on a new video card,when there are cheaper options available. (Especially considering how cheap the Poser/DS customer base is.)

The decision on file formats was built on the idea that the DS content would reside on DAZ's servers and would be pushed to the enduser's computer (This was how DAZ was looking to deal with the whole "casual piracy" issue - can't actually pirate something that doesn't leave Utah.)  Good idea, but it doesn't take into the account of Time Warner Cable & Comcast being between DAZ's servers & it's customers.  DAZ isn't the only company that didn't take that into account - every company that pushes moving your data back to the mainframe (AKA "The Cloud"), is making the same mistake. 

There are still references to it along with a fairly concise explanation of why JSON was chosen in the SDK documentation.  I would also send you to the PC forum over at DAZ, but all of the screaming & shouting over this was deleted when DAZ moved to the now dropped forum software a couple of years ago.  For that matter, dig around on You tube, there are still demonstrations of it available - the infamous web-based version of DS4.  

DSON damned well stuffs every morph it can see into a figure when it builds the .obj - it can't be any other way, it is a function of how the original spec was designed.  I have a test folder that the DIM uses to dump anything I purchase from DAZ. I went with that because I knew nothing about how DS worked and I understand that when learning software, start with everything at default status until you know what you are doing.

Using a content library that was DIM default designed, I loaded up a V5 - it took almost 15 minutes to build the figure out & it installed EVERY SINGLE MORPH in that base folder. I had every V5, SP5, A5, M5, YT5, H5, F5 and every 3rd party morph load into the figure, and it was right at 1Gb.  The only way to get around that is to build separate folders/runtimes and only load what you plan on working on (This also works for DS4 - unless you don't mind drilling through literally dozens of folders, many of them only holding a single subfolder looking for something.)

OTOH, if you know how to load a genesis figure via DSON WITHOUT having it load every morph it can see, I would certainly like to know about it - I haven't found anything that covers that in the "documentation center".

Moving right along, maybe you don't mind spending a couple of hours individually deleting 86 empty file channels that DSON creates under the HIDDEN dial - I do - those are memory hogs.  Perhaps you don't mind playing the Where the hell did they put expressions this time? I do.  Consistency may be the hobgoblin of little minds, but my time is valuable, and I don't feel like playing Magellan every time I use a genesis figure.

Then there is the whole lets scatter files everywhere. Vendors don't follow what few guidelines DAZ does provide.  I have vendors that stuff all of their content into a single folder that duplicates everything in a standard My Library or Content (depending on which "standard" the vendor follows). The user facing files in the People subfolder are a mess, due to the proliferation of "ego" folders (and the ads - what the hell is up with that?  If I buy something from DAZ, I KNOW the vendor sells there).

Maybe you don't mind drilling through half a dozen folders (many of them only holding 1 subfolder) while looking for a product. 

And of course there are the addons for products that have no identification of what product they go to, cleverly hidden away in the vendor's subfolder as opposed to the base product subfolder.

The user facing files assume that the end user knows who made every product (another consequence of having products that are vendor focused as opposed to customer focused).  This is why there is a proliferation of  3rd party library programs for DS - the DS system architect (In spite of all evidence to the contrary, I do believe that DAZ has one.) failed in one of their most basic functions.  Hence, months of experimentation figuring out the most efficient layout for my DS content.

In the Pose subfolder, I have had the following PCFs dumped in it:

.cm2 - Camera files

.cr2 - Character files

.lt2 - Light files

.mc6 - Material files

.fc2 - Face files

.hr - Hair files

Any product with PCFs means that I am going to spend 20 minutes or so putting everything where it belongs - all because DAZ "QA" doesn't actually check the PCFs locations.  Don't try to feed me any line about how they do - There is no point to having a standard, if it isn't enforced.

If we are being totally honest, there's no point in your rant. You don't have to worry about PAs creating PCFs any more. More complaining than actual use put the nail in that coffin.