My own comfort zone is with plain CSS and Sass. I find their logic simple and the separation of concerns keeps my HTML tags shining and readable.
The component-focused paradigm just clicks for me. This preference is actually why I haven’t picked up Phoenix Framework in years, as its Tailwind integration doesn’t align with my style.
The good news is that you don’t need to use Tailwind with Phoenix! Let’s not throw the baby out with the bathwater here.
plain CSS and Sass
When I read this I always wonder…
$light-gray, $color-light-gray, or $color-gray-400. And so on..text-right, max-sm:hidden? Do you have a utilities.sass file?It feels to me you would end up doing a lot of the same things that Tailwind has already figured out. Or am I missing something, do tell let me know of course 
I agree about keeping HTML readable btw 
SASS/SCSS variables
Usually I find a palette that I like. For no-nonsense apps I usually take the colors from Tabler.
My “public” variables are semantic, like: $control-color--contents--fg , $control-color--contents--bg etc., but they are defined using some “private” variables like $-blue, $-blue-lt, $-blue-dk etc.
I separate words with -- and prefix some classes with one-character prefixes like c for component and p for page. So c-control--button--xl for an extra-large button. My button component (in Web.Components.Control.button) has a size attr and the component sets the class like <a class={"c-control--button--#{@size}"}>. I could theoretically automatically generate the class names based on the component and function name, but I haven’t found the need to do that yet.
I never use utility classes. (Unless I’m using Tailwind or its predecessors, which I personally prefer not to do.)
I personally find it easier to edit SASS/SCSS than to edit a long list of utility class names.
I create a styleguide (which I think other people call a “storybook”?) that contains each component and its docs, as well as various examples. When I want to make a change to a component, I often view the changes in the styleguide so that I don’t forget to create examples of the various features of a component (kind of like test-driven development for components, except that there’s no automated feedback). The styleguide is just a single LiveView that has some navigation links to jump between components.
AI is really good at these types of refactors because it can knock out the tedious and repetitive parts quite reliably. We just did a complete front end redesign (150k lines of Vue.js) using Opus 4.5. What would otherwise have taken us weeks took just three days, and that was mostly watching the AI work and then verifying the results.
Tailwind does a lot of things that have already been figured out elsewhere, true 
There are two main approaches when working with styles. The first is designing directly in HTML, which is primarily used for quick prototyping. This involves using the style=“” attribute. Tailwind CSS is an extension of this approach.
The second approach is “design-first.” Using Sass (or a similar preprocessor) is very helpful here. You begin by writing a _variables.scss file, typically between 50-100 lines. It is best to define colors, etc semantically, such as $color-primary, rather than literally, like $color-gray. This allows you to change your entire color palette with minimal effort.
You will also create a _main.scss file for global styles and can start with something like _detail-page.scss for page-specific styling. When following a mobile-first methodology, you write the desktop styles directly within the same class, using media queries.
Ultimately, you’ll have around 10–20 style files, each approximately 50–100 lines. By using a tool like a monorepo alongside a development server such as Vite—which is perfect for this—you can design and test several sites with live reloading, all sharing a central design system.
Your template will then be robust and maintainable for 5–10 years with only minor updates. For each component, you’ll typically work with no more than 10 classes to consider. In projects with multiple developers, this approach makes it extremely straightforward to identify and correct any inconsistencies in design implementation.