it's really theory (CS) vs building things (SWE). As you want to build larger projects, or build them better, you rely on CS ideas to do that. So SWE is really engineering assisted by applied CS. I've been studying CS for about two years and am only now learning any real application development. You can study CS without ever touching a computer or building an application (though doing both those things will give you context for why CS topics matter).
It's kinda like if you want to build a rocket to get to space, you can tinker with propellant, metal, and fire, and be a hobbyist that eventually you build a rocket to go to space. Or you can be a physicist and calculate everything on paper. To get to space you really need both those people, but the physicist can learn to build and the engineer can learn theory.
> but the physicist can learn to build and the engineer can learn theory.
So is this why frameworks exist? To abstract away the theory that proves something more "performant" or "sufficient", and allow the builder to do their thing?
More or less yes. The idea is that a framework (ideally) does some feature A the "right" way and programmers using the framework gain the benefits of convenience and safety, often at the cost of flexibility. Frameworks will usually try and balance the power or depth of the domain its abstracting with ease of use.
A good framework will stop beginners from making critical mistakes, decrease the amount of code its users have to write, and offer professionals well-constructed ways around its handholding as needed.
It's kinda like if you want to build a rocket to get to space, you can tinker with propellant, metal, and fire, and be a hobbyist that eventually you build a rocket to go to space. Or you can be a physicist and calculate everything on paper. To get to space you really need both those people, but the physicist can learn to build and the engineer can learn theory.