But once you have abstract S/M/L/XL estimates for some tasks, what do you do with that information? How many S tasks are equivalent to 1 M task? If the team completed 3 M tasks and 3 S tasks last sprint, how does that help you plan for your next sprint? While story points have their own issues, at least tasks' relative size differences are clear and different tasks of different sizes can be scheduled.

Story points are relative measures (at least when you do it 'right').

What is so different from estimating things as 1/2/5/8 or S/M/L/XL?

S (or 1) is roughly half as hard as M (or 2).

M (or 2) is roughly half as hard as L (or 5). Notice how 2 is not exactly half of 5. Just roughly.

And so forth.

And the point is that you can't say how many S are exactly equivalent to how many Ls. Estimates tend to get less precise the larger they are. There's usually more uncertainty built into large estimates which means once you do the work it might be much faster or much slower because of things you didn't look at very closely when estimating. While small things are easier to have a complete overview of and the estimates are more accurate.

A recent example from my work. There was something the team unanimously estimated as L. I knew it was an S. I knew the code though and they didn't. I let them put the L estimate on it. When the sprint started and I had some time I did the task myself and it really was an S in the end. But that's fine. They 'priced in' the uncertainty. If one if them had done it, it might very well have taken them longer because if not knowing the code as well.

You don't; you ease your executive/sales/etc partners into the new world where they get better software, faster features, and fewer outages, but they give up release dates and micro-managing the roadmap. Calling an epic "Large" instead of "237 story points" is a way of forcing yourself to accept that you only have a rough idea of how long it will take.