If your goal is to understand in detail how the microcontroller works, then just use the register declaration file (stm32fxxx.h) and work directly with the hardware. It is not that difficult, and for some peripherals I would argue it can be much simpler, as the ST libraries add a lot of framework code that few people really need. Once you've learnt how to configure and use each peripheral you will probably want to use a library to do the boiler plate work, but at that point you'll have the knowledge to be able to decide if you want to roll your own, or use one of ST's offerings (and importantly debug those libraries if you end up using them).
Also note that CMSIS is a bit different from the other sort of 'hardware abstraction' libraries you might be looking at. Essentially, it is a very lightweight vendor independent software layer defined by ARM for managing core CPU support functions (interrupts, fpu, memory etc). The reason they created this is that in the early days of ARM microcontrollers, ARM only supplied the core CPU. These were not initially developed for single chip microcontroller work, so they had a very simple interrupt handling scheme - basically just a mechanism for saving CPU state and branching to a single vector on the assertion of the IRQ line. If you wanted to have different interrupt sources, then the chip vendor had to add an interrupt handler peripheral. The problem was that each vendor started developing their own interrupt handling systems, and this meant that code could not be ported so easily between chips.
When ARM released the Cortex-M line - specifically targeted at microcontroller applications - they built in some of these more common support peripherals with the CPU core IP. To provided access to these peripherals they also defined the CMSIS.
In practice you will almost always use the CMSIS libraries in your projects, but you should be able to see from the source code that much of it is really just register definitions, and it is very lightweight.