How is it ad hoc? You're creating a class .button, but you're using the Tailwind-specified design system. This is how the framework is meant to be used!
Atomic/utility-first CSS doesn't mean that you shouldn't make classes. It just means that you should make them where they make sense. Don't make a new class just to add a margin to something,or whatever. If the margin is literally all this element needs, use the utility class directly. If it's the only place you'll use this combination of classes and naming the combination doesn't add anything, you might as well just keep it inline.
But if you find yourself repeating a bunch of utility classes, make a class with a semantic name once you start seeing the pattern. In some cases, like buttons, you might see that pattern before you've even started. That's fine. You should definitely have a button class (or three).
What you (probably) shouldn't have a is .info-page__navigation__aside__second_button that just includes the button class and adds a margin, or whatever... like we did at my old job. Urgh. I refer to this as "might as well be inline CSS" - making extremely specific classes that are only used once. If your CSS classes aren't reusable, all you gain from not having it inline is the joy of maintaining two text files, and manually look up the cross references. Tailwind solves this perfect, IME.
Not everything requires making a component. A CSS class can be fine, and I'd always use the least powerful way first. This is how the framework is meant to be used - that's the entire reason for having @apply.
I don't understand what you mean by ad hoc. It's a very structured approach. When utility classes don't work, you make a semantic class. If that doesn't work, you make a component. You can even use BEM naming if you want, you'll just be making a lot fewer classes.
