Is optical mostly a waste of time versus Ethernet?

If using Roon none. If using and of the streaming services which are all TCP based with buffering and retry, none. If using something locally like HEOS, DLNA, etc. not sure all would need to be evaluated (on paper). I remember not long ago seeing a test with JRiver (not sure what protocol) and there were lost packets. That’s not a JRiver issue, just what protocol was used for that connection. In my local network, I have done tests wired and lost no packets over 30+ minutes. WiFi you lose packets but I don’t think anyone would use a protocol with WiFi that loses packets.

Optical greatly increased the SQ in my system.  Use two Cisco 2960's or Marika 220s cascaded by fiber w/ startech.com sfp's. You can add a shunt and lc filter to the power supply for even further improvements. 

Read the following on PACKET LOSS, Which can happen even on TCP streaming, contrary to the EXPERT opinion on this thread. This can happen when congestion of the network occurs. Which I said I can demonstrate 100% of the time with a low bandwidth setup of ROON Core.

John Swenson is someone who is an actual streaming audio expert and no one so far on this thread has shown they are an audio streaming EXPERT.

Great thing about Swenson ideas is that it is not very expensive to implement. If you have functioning ears and a decent setup you should easily hear the improvements from Swenson's setup for under $2K.

I personally have not got any expensive networking gear in my streaming chain. 

Reading something and understanding what it means in application are not the same. TCP ensures all packets are delivered including the logic to resend if lost.

Network transport protocols such as TCP provide endpoints with an easy way to ensure reliable delivery of packets so that individual applications don't need to implement the logic for this themselves. In the event of packet loss, the receiver asks for retransmission or the sender automatically resends any segments that have not been acknowledged.^[3]: 242 Although TCP can recover from packet loss, retransmitting missing packets reduces the throughput of the connection as receivers wait for retransmissions and additional bandwidth is consumed by them.

Sure, packets can be resent byTCP. However, think about how streaming works. It is a continuous flow of music. You have packet loss and then what, the sender resends it so you will likely hear a regurgitation of the sound that was attempted before.

A buffering mechanism on the DAC may elevate some of these issues. Where do you do that buffering? The DAC would be the best choice but there are 100’s of DAC brands out there and likely no standard on buffering.

Now how about streaming internet radio? Resending packet sure would be interesting.

What seems to be common is that on guaranteed delivery TCP. When the network gets congested, The sender will throttle down so as to lower the congestion on the network and the packets will be dropped. This common practice is quantified as Quality of Service (QoS). That is a measure of how much packets were dropped on a network, including TCP.

Wow, all that just form reading.