DB snapshots work on the basis of copy-on-write. Read operations of data that is unchanged since the snapshot was taken are fulfilled by pages from the original database. If the data has been changed, the original version of the data is copied to the snapshot so future queries will use pages in the snapshot. When you have multiple snapshots, there is a potentially intricate collection of pages in each snapshot depending on how much write activity took place and how much of that was on the same data. You could end up with many generations of data where each generation resides in one of the snapshots.
This means all snapshots are individually, tightly-coupled with the original database. If you restore the original database using one of the snapshots, that effectively breaks the coupling for all other snapshots hence it isn't allowed.
Third party solutions from storage vendors keep copies of the data around by retaining and tracking blocks that each snapshot is dependent on. That means you could end up consuming storage space many times the size of the original database depending on how many snapshots you have and restores you make. It gets expensive and very complicated quickly.
If you're using multiple snapshots to get different point-in-time data, suggest you consider temporal tables in SQL Server 2016.