I don't have to context-switch and open a different file to be able to reason about the styling on an element
Unless you're coding on a VT100 terminal, you just put the HTML in one window and the CSS in another. Subdivide as necessary, or as your monitor space allows.
Heck, we were doing that back in 1989 on IBM PCs with MDA displays.
If your CSS is so out of control that you can't wrap your brain around it, it's time to refactor or split into individual CSS component files.
Even if one were limited to a single window, I’d hazard to guess that most modern web frameworks and languages have some degree of templating and pre-processing capabilities, which let you have logically contained files with HTML and CSS that decompose/render into separate files.
I’ve made setups like that on a number of projects (ASP.Net & various .Net web frameworks). keeping clean separation of concerns, proper cascading, but also a simplified development experience where the ‘component’ file contained all relevant code, markup, and local styling.
Maybe even split it into a set of small reusable coherent utility classes
VT100 for life!
But more seriously, I should have been more specific. Having the second file open in a split pain isn't that big of a deal, but having to navigate and find the right selectors can be. If class names are used well then it's pretty easy to find those, but my experience with that is riddled with inconsistency when I'm not the one who wrote it.
On that note, it's also much easier to review CSS changes in pull requests when they are right in line with the file. Otherwise I have to do the same lookup to find the corresponding HTML, and reason about whether the selector could potentially be grabbing things that aren't obvious, etc.