> It's not necessarily a good idea to completely separate what things are and how things look. It indeed makes easier to do a complete redesign, but how often does it happen? And if it does happens, what are the chances that it actually won't require markup changes?
If the markup is done properly in the first place. It is incredibly easy to restyle and you typically don't to rework much markup. It just ends up working.
> but it allows much much faster development, less spaghetti styling, less cross-browser concerns and less code all around.
I have seen no evidence of this in practice. This is only true if you design is basically a skin of these frameworks. If you have anything remotely custom you end up overriding so much you might have well just started with a normalise/reset style-sheet. So for some internal application that never seen on the outside, you can use bootstrap and slap something together quick sure. However if you are actually building something with a unique it just doesn't really work.
If you think about what you are doing instead of just jumping in and coding. You can break stuff down properly without the need for hundreds of classes that typically come with these CSS frameworks. You do end up with clean CSS and the markup is clean and you do have less code.
By doing things properly i.e. you markup and css is correct. You have less cross browser bugs. I end up in my current being asked by a coworker to pick up IE bugs (yes we still support IE9 upwards). Only 10% of the fixes are actually problems with IE. 90% of the problems are correcting the markup (making it valid) and cleaning up the CSS and it just works cross browser. Sure you will have to work around things like you don't have flexbox and other niceties and you have to use an alternative style-sheet. But fixing the markup normally gets it from "not rendering properly at all" to "rendering only slightly wrong".