A big benefit I see is the constraints it introduces. If another developer comes along, they know there are a few options for padding. Rather than guessing and setting some pixel value (or should it be in em, or rem?) or having to refer to other code or documentation, they can just look at a design document and say "that looks like a p-4", done.
Tailwind also makes things much more flexible than using inline styles: I can add a brand colour to my Tailwind configuration, and I immediately have utility classes available for text, background, fills, hover and focus states, etc. I can update one hex value rather than refactoring every inline style in my app. You could do this with custom classes, but frameworks like Tailwind mean I can hire a new developer and they don't have to look through a stylesheet and memorize potentially hundreds of style definitions and class names. I think this standardisation can be very useful.
[0] https://tailwindcss.com/docs/utility-first#why-not-just-use-...
with that said, it's an internal tool - who give a hoot?
I usually do 2 things when styling my crummy internal sites: a) manually write semantically-named classes for things that need it ("help-text", "external-link") and b) just in-line styles for everything else (esp. when a style really only applies to one element, or is intimately related to important layout considerations).
It seems to me that css classes which contain styling info in their name (h-32, font-semibold, text-cyan-600) aren't really any better than just in-line styles, and in fact maybe worse because they [seem to me] to just be an alias [which I have to learn, and will forget later] for a css style. Wouldn't it be simpler to just inline the style?
So my question is: what's the real benefit of this kind of css framework? What are the scenarios where it really helps to do styling this way? Is it just a performance thing? Is it about streamlining a dev workflow in some way that I don't get?