A core part of Tailwind is that you reuse styles by using a templating system vs using custom CSS classes e.g. you have a button.html file that contains the styling for your buttons for reuse, so you don't have to keep repeating the same utility classes everywhere.
https://v2.tailwindcss.com/docs/extracting-components#extrac...
> It’s very rare that all of the information needed to define a UI component can live entirely in CSS — there’s almost always some important corresponding HTML structure you need to use as well.
> For this reason, it’s often better to extract reusable pieces of your UI into template partials or JavaScript components instead of writing custom CSS classes.
@apply (e.g. .btn { @apply py-2 px-4 bg-indigo-500 text-white }) is only meant for reusing styles for simple things like a single tag and is generally recommended against because you should use templates instead:
https://v2.tailwindcss.com/docs/extracting-components#extrac...
> For small components like buttons and form elements, creating a template partial or JavaScript component can often feel too heavy compared to a simple CSS class.
> In these situations, you can use Tailwind’s @apply directive to easily extract common utility patterns to CSS component classes.
Inline styles can't be responsive and can't target hover/focus states e.g. there's no inline way to write "text-black hover:text-blue py-2 md:py-4 lg:py-5 lg:flex lg:items-center" and the CSS equivalent is very verbose.
https://v2.tailwindcss.com/docs/utility-first#why-not-just-u...
> But using utility classes has a few important advantages over inline styles:
> Designing with constraints. Using inline styles, every value is a magic number. With utilities, you’re choosing styles from a predefined design system, which makes it much easier to build visually consistent UIs.
> Responsive design. You can’t use media queries in inline styles, but you can use Tailwind’s responsive utilities to build fully responsive interfaces easily.
> Hover, focus, and other states. Inline styles can’t target states like hover or focus, but Tailwind’s state variants make it easy to style those states with utility classes.
Opinion: As utility classes are quick to type and change, and it's easy to find where you need to edit to change the styles of a component, it's an order of magnitude quicker to iterate on designs compared to CSS that's scattered across files and shared between pages in hard to track ways. CSS specificity and cascading aren't often used, and mostly just cause complexity and headaches so are best avoided. Tailwind-style vs classic CSS is similar to composition vs inheritance in OOP with similar pros/cons, where complex inheritance is generally discouraged now in OOP languages. Yes, the Tailwind approach is going against the standard CSS approach, but CSS wasn't initially designed for highly custom responsive designs so it's not surprising if its "best practices" don't fit everywhere.
Also, Tailwind is really for custom responsive UI and website designs. If your site is mostly Markdown documents and you don't need a custom design or complex mobile/desktop styling, the above isn't going to make any sense and plain CSS or something like Bootstrap is likely a better choice.