The way I think exploration in this group should be going is to seriously examine what engineering steps can be taken to deal with leap seconds properly. This means looking at changes to Posix and NTP, new protocols for disseminating leap second information, new APIs for accessing clock information with different properties and so on. Also, possible changes to leap second scheduling to give longer notice. If, taking all of those together, we find that there are important use cases which cannot be covered then we've made a good case for scrapping leap seconds.
The obverse is to look at the use cases (e.g., in astronomy and navigation) which require UT1 (or other Earth orientation information) and look at ways for them to recover that from an atomic timescale. If there are, again, any important use cases which cannot be covered then there's a good case for keeping leap seconds. My suspicion is that actually all cases are reasonably easy to deal with with only a little care. In that case, it becomes an engineering trade-off - which of keeping or scrapping leap seconds causes the least hassle. Starting from a clean slate, I'd guess that doing without leap seconds would be the right answer - at least now, though probably three decades ago the right decision was made for that time. On the other hand, they're here now and I'm far from sure that change would be worthwhile and we don't know for sure what the balance will be in another three decades. What isn't helpful is to have two groups each starting from an assumption or even definition that one or other answer is right repeatedly shouting past each other - particularly using arguments which are tricky to the point of dishonesty, blunt rudeness, personal attacks and so on. I hope we can all continue this discussion in a more positive manner. Ed.