I disagree, if it fully validates, then it's part if the network, and does its job for the network, pruned or not pruned.
'fully validating' is a service purely for the user using the node to trust the data it got. its not a 'network' service
'fully archive' is a network service for other nodes to get data for their syncs
a prunned node cannot offer old blocks of say the first 5-9 years of bitcoin, thus useless for network services.
its stuff like prunned being treated like full that gives issues like what 'hatshepsut93' experienced. because even without any hardware or bandwidth withstraints i presume the nodes he was connecting to were not full network service nodes
imagine it like torrents. you see torrents list for a movie that has many users, but. 98% of users have only downloaded the packets for the final 10 minutes of the movie (the credits/casting list) it doesnt matter how fast the intrnet is or hard drive space is. by listing these 98% as seeders means theres only 2% chance of getting the full data.
and if your not keeping an eye on it to cancel download to particular user to then search out a better source. you nd up just waiting for the other user to disconnect themselves before your system rescans for a new source
...
anyway back to the topic of SSD vs HDD
when a system uses a hard drive as its 'virtual memory'/paging file(extended ram utility) then it makes a difference of th read/write speed. but just archiving the blockchain. thats more of a background activity after all the validation stuff is complete thus not really affecting the network propagation. after all a average old 7200rpm hdd is atleast 80mb/s.. blocks are not even 3mb so storing a block which occurs in ~10 minutes, takes less than a second.
so the real limitation is not really ssd vs hd for archiving. but actually ram utility for the validation/UTXO store