why expensive streamers

The memory would assure that the analog noise and timing errors from the server would not affect this DAC circuitry.

That is not quite correct.  The buffer memory on the DAC is there to ensure there is no underflow - that is the data will always be there.  The memory buffer is not intended to isolate the noise.  The noise from the streamer can potentially affect the DAC timing.  This is true for asynchronous USB. The noise on the ground and supply of the streamer can inject directly to the DAC circuitry.  That is why some DAC uses optical isolation which minimize the coupling hence reduce the noise.

For S/Pdif it is a little bit different but in this case instead of a streamer, you have the transport noise affecting the DAC.

@andy2 there are many types of memory and storage. I am saying if there is an issue with noise coming through the streamer interace a designer could easily solve the issue. All they need to due is use something called an asynchronous fifo. The sole purpose of this fifo would be to take care of the streamer noise. The buffer memory you mention would be a conmpletely different piece of hardware performing a different function. I sure there are multiple different memory elements in a DAC.

@andy2 

So, if you connect your server to your streamer using an optical cable, and USB from the streamer to a DDC that reclocks, and then a short s/pdif or AES/EBU to the DAC, are the bases mostly covered? 

 The sole purpose of this fifo would be to take care of the streamer noise. 

I don't think the FIFO (or what I called a memory buffer) can isolate the noise.  I think you may be referring to data jitter - I am talking about ground and power supply noise.  The noise from the streamer can inject directly to the ground and power supply of the DAC.  I am not sure that the FIFO can fix that. 

As for data jitter, yes the FIFO can eliminate that if you are using asynchronous USB interface.  All you have left is the jitter of the DAC clock itself. 

So, if you connect your server to your streamer using an optical cable, and USB from the streamer to a DDC that reclocks, and then a short s/pdif or AES/EBU to the DAC, are the bases mostly covered? 

If I understand correctly, what you have is a s/pdif interface to the DAC - it's not asynchronous USB.  So you're still dealing with the data jitter in the spdif interface.  Spdif is a synchronous interface so you still have to recover the clock from the data stream.  If the data stream has jitter, then the recovered clock also has jitter.  Basically the the clock has to move with the data.  

DCS solves this problem by using what they call "reverse clocking".  Basically you have the clock of the DAC clocking the data stream from the transport or streamer.  In this case you would have something similar to asynchronous USB clocking.