Cube sucks. The only thing i find it useful for is planning pin usage in a processor.
I keep a policy of not using anyone elses code, only using my own. I have made exceptions from this for really atrocious stuff (USB, TCP, Modbus...) where i focused on getting somebody elses shit to work, but in general I only use my own code. I do use helper libraries like the ST's SPL, but only after i review the code line by line. I work from plain register definitons if need be. Save the "one code fits all" stuff for linux users with GHz's and GB's.
I have learned this while working with Mircochip's pic24f library, which gave me a week of hair-pulling because the library was not compatible with the mcu I was using (despite it claiming to be)... and the mcu had an extra configuration bit.
As for general quality:
ST: very good silicon, good documentation, SPL is ok, CUBE is shit
Atmel: silicon is ok, documentation is generally ok although sometimes lacking (mostly manageable after examining the examples provided), IDE is shit, or rather adapted to MCU use in a shitty way (no 'binary' display in debug mode? - come on!)
NXP: good silicon, good documentation, crappy policy towards low volume users, hobbyists and open source crowd (eg. they won't disclose the debugger protocol to OpenOCD people)
TI: good silicon, good documentation, ok libraries, but chips are expensive and they do not cover the lower range too well
Microchip: silicon=mostly shit, documentation os ok, compilers and IDE are shit. $40 genuine debugger is an example to show to other manufacturers
Freescale, Silabs/EnergyMicro, Cypress: can't say, I've never had much practical experience with them (i serious project I mean, I dabbled a bit with some low-end devboard)
This is mostly true for me too, although I do accept the use of hardware header file, CMSIS basic headers and a third party C library (newlib.)
Here is an example of what I am talking about.
Cube for me is only an interactive part selector and pin planner, occasionally a clock tree reference.
Vendor HAL is crap from my perspective (be it ASF, MCC or Harmony from Microchip or Cube from ST) so I am avoiding those as much as possible. A good HAL need to be platform and vendor agnostic, so those "vendor HAL" flat out does not meet this criteria. A good example of a good HAL would be the Arduino API.
In my own code I do use HAL - a mix of POSIX API and Arduino API for features not exist in POSIX.