A lot of people seem to approach Tailwind as a set of helper classes, but I think this is a misunderstanding of what Tailwind is doing.
It's clearer to think about Tailwind as a DSL for writing CSS directly in your templates. If that sounds like a thing you don't want to do in the first place, then Tailwind probably won't add anything useful for you, but for a lot of developers, it's a very convenient way of encapsulating style, structure (and potentially behaviour) in a single unit. You can then compose these units together to create larger systems.
Like I say, that's not the only way to develop for the web, you can also take the approach of separating out style, structure, and behaviour, and there you're not really going to see much benefit from Tailwind directly.
Specifically, I think a lot of the success of Tailwind comes from the fact that it's very agnostic about how you build your units. A lot of tools for CSS encapsulation have typically either been bound to a single framework, or at least very bound to the Javascript ecosystem. For example, CSS Modules do in many way a very similar thing to Tailwind, but they're heavily connected to the JS concept of importing and bundling - they can't easily be used in Python, for example. On the other hand, Tailwind is just text - if the Tailwind compiler finds a file where you're using its DSL, it can build the correct CSS files from that, regardless of how the file has been written. This allows you to use Tailwind from HTML, JS, but also from arbitrary custom templating formats, or even other programming languages.
I don't think Tailwind has so much to do with "basics vs helper methods". To do a lot of useful things in Tailwind, you need to know CSS in the first place, and it really is just a DSL around arbitrary CSS declarations (although the more complex those declarations become, the less pleasant Tailwind becomes to use - it is by no means perfect, or even my favourite tool for encapsulated CSS). It's more a question of how you want to write your CSS: do you want to write it coupled to HTML in components, or so you want to write it decoupled as a whole-page stylesheet?
It's clearer to think about Tailwind as a DSL for writing CSS directly in your templates. If that sounds like a thing you don't want to do in the first place, then Tailwind probably won't add anything useful for you, but for a lot of developers, it's a very convenient way of encapsulating style, structure (and potentially behaviour) in a single unit. You can then compose these units together to create larger systems.
Like I say, that's not the only way to develop for the web, you can also take the approach of separating out style, structure, and behaviour, and there you're not really going to see much benefit from Tailwind directly.
Specifically, I think a lot of the success of Tailwind comes from the fact that it's very agnostic about how you build your units. A lot of tools for CSS encapsulation have typically either been bound to a single framework, or at least very bound to the Javascript ecosystem. For example, CSS Modules do in many way a very similar thing to Tailwind, but they're heavily connected to the JS concept of importing and bundling - they can't easily be used in Python, for example. On the other hand, Tailwind is just text - if the Tailwind compiler finds a file where you're using its DSL, it can build the correct CSS files from that, regardless of how the file has been written. This allows you to use Tailwind from HTML, JS, but also from arbitrary custom templating formats, or even other programming languages.
I don't think Tailwind has so much to do with "basics vs helper methods". To do a lot of useful things in Tailwind, you need to know CSS in the first place, and it really is just a DSL around arbitrary CSS declarations (although the more complex those declarations become, the less pleasant Tailwind becomes to use - it is by no means perfect, or even my favourite tool for encapsulated CSS). It's more a question of how you want to write your CSS: do you want to write it coupled to HTML in components, or so you want to write it decoupled as a whole-page stylesheet?