I'd like to know understand what circumstances you'd use a span instead of a button.

I always thought the point of tailwind was to write less css. It's a replacement for bootstrap and other similar libraries (which also suffer from the issues you point out).

Please, do not use span for buttons 😢

But in this example you explicitly tie .blue and .small to button, without making it obvious at first while looking at HTML.

I can read this HTML and think to myself "Hmm, is this .blue color: blue, is it a class that I can apply anywhere I want, is this .small font-size, or maybe height? And so on...".. Then I go and use .blue somewhere else and see that it doesn't work and then I go check CSS source and see that it's only tied to .button. Then you go make a card component and want that same background color and you create .card.blue and duplicate the same background color. Now you have a class .blue that seems like it's something generic, but it's actually really tied to some elements you have and you also increase specificity by using .class.class selector for no reason.

This isn't really "rolling your own Tailwind" because you didn't make these classes generic, you just coupled them with this single element and they are not usable outside of it.

I haven't really used Tailwind that much, but purpose of it is to give you these single purpose classes that you combine (compose) into something that you want. Yeah, it might not seem clear what you are looking at when looking at HTML at first because of the learning curve and overhead of remembering what all those classes do, but neither is just

<button class="btn blue small">Allegedly Small Blue Button</button>

By using Tailwind, you only use what you need and don't repeat css properties multiple times for no reason

.button.blue {
  background-color: #3366CC;
}

.card.blue {
  background-color: #3366CC;
}

.avatar.blue {
  background-color: #3366CC;
}

...

And after using a build step, you strip out all unnecessary CSS and you are only left with what you truly used, without repeating stuff, leading to a smaller more optimized bundle.

It's also easier for browsers to apply a single class to 50 elements, instead of those 50 elements being targeted by many different classes that all apply mostly the same properties. You also avoid higher specificity because you don't combine .class.class selectors.

As I've mentioned, I personally don't use Tailwind, but I still like some general purpose classes, especially for padding/margin. It makes building UI easier, you make spacing consistent and you don't repeat yourself writing margin-bottom: YYpx a bunch of times for multiple elements.

I haven't yet switched fully to utility first, but I do see the benefits of it. Personally, I combine BEM with a healthy dose of utility classes. I do partially like utility approach because it allows you to iterate fast and adapt design as it might change. It also allows me to prototype faster. We've all had designers change stuff on us quickly and maybe "mess" things up for us in our "perfectly crafted CSS", but when using utility classes I can easily overcome it and all of a sudden those "sudden changes" in UI design don't really stress me that much.