Says something about how Facebook sees itself, I guess.
Leap seconds are exactly the "screwing around" you criticize.
Neither do I in day to day life. But I do have to care about it when I or members of my team write code, or store and retrieve data to and from a database, or work across multiple timezones, because it can be critically important to unambiguously know whether something happened on one day or the next.
The reality is there aren't any nice, elegant solutions to this problem. Leap seconds aren't a nice solution. Meta's proposal isn't a nice solution. I don't necessarily even think it's worse than leap seconds, but it's certainly not substantially better. The key point is it's a change and one which, in my view, won't deliver enough value for everybody (beyond just Meta) to justify the level of disruption it will certainly cause if implemented.
Let's paint a picture based on actual code I've actually seen in the real world. If you ignore the leap second but keep using UTC, then in about 5 years, UTC will differ from wall clock by about 5 seconds. So if, in some software used for, I don't know maybe billing customers, someone was calculating day boundaries by doing modulo division of UTC by the number of seconds in a day (I've seen it), then in 5 years we've got a 5 second discrepancy in the number of API calls made by customer X when comparing what the software says to what the customer measured. Customers don't like this, accountants and lawyers REALLY don't like this, and us engineers will have the wonderful experience of telling them all
> "this code used to be valid until some boneheaded engineers at Facebook convinced a ton of other engineers to break the agreed upon standard about what it means to measure time in this way, and now things that used to work fine need to be patched because we've got a Y2K EVERY DAY!"
Oops, I guess ignoring wall clock time might be something other human people care about after all.