2. If you need to use the same group of utility classes over and over, extract to a class - either with @apply (if you want to keep the flexibility of config updates) or vanilla.
3. I'm not sure I'm following here - if you're changing the value of a tailwind class, you should do that via the config
4. I've found the naming differences easy enough to follow - line-height vs leading makes sense if you come from a design background. I think the biggest gotcha I had early on was everything is mobile first by default - so sm:* is actually _larger_ than the default.
5. the JIT is a wonderful addition, but does come with overhead currently - so that's why it (i assume) isn't just the default way of doing things.
6. not a problem i've run across, but why would a component config supersede an app config?
to your last point, we use tailwind in conjunction with a fair amount of legacy sass to do what we need (many small nuances, spread across 4 different sites, that are otherwise the same) - I would urge against mixing tailwind and SASS if only for the build speed, PostCSS should be able to do everything you need there and it'll just make the builds a bit faster.
tho I feel like what myself and my team works on is a far cry from your standard HN web app - so my experiences are probably very different.