I've experimented with this strategy -- avoid putting bootstrap classes directly in markup, but instead use CSS pre-processors to mix bootstrap classes into your own css classes.
I've found it's less maintainable, in the sense that the extra level of indirection becomes a lot more confusing to debug or change. Dealing with a bootstrap upgrade (minor or major) only makes it worse.
The presentational classes in your markup does give me a bad feeling. Maybe if Bootstrap had been designed from the start to keep your DOM purely semantic and your presentation purely in CSS, then it would result in a framework that can more easily be used that way. However, there are other frameworks that tried to do this; they haven't been as successful (ie popular) as bootstrap, and it may be that some of the reason why is the extra complexity it takes to try and keep presentation and semantics strictly separate.
There is such a thing, sometimes, as too much abstraction. When we start calling it 'over-engineering' or 'too complex'.
I've found it's less maintainable, in the sense that the extra level of indirection becomes a lot more confusing to debug or change. Dealing with a bootstrap upgrade (minor or major) only makes it worse.
The presentational classes in your markup does give me a bad feeling. Maybe if Bootstrap had been designed from the start to keep your DOM purely semantic and your presentation purely in CSS, then it would result in a framework that can more easily be used that way. However, there are other frameworks that tried to do this; they haven't been as successful (ie popular) as bootstrap, and it may be that some of the reason why is the extra complexity it takes to try and keep presentation and semantics strictly separate.
There is such a thing, sometimes, as too much abstraction. When we start calling it 'over-engineering' or 'too complex'.