SPL is out of date. The HAL ancestor.
STM offers the HAL in order to allow basic users to use the resources of the MCU. Like any Hardware Abstraction Level library it tries to be generic and therefore it is complex and inefficient. In addition, you must adhere to the architecture chosen by ST, which may be very different from what you would have done.
For complex peripherals (USB, Ethernet...) this is the best way to use them proposed by ST.
There are also LL (Low Level) libraries. It is a set of declarations and utility functions.
Useful declarations concern for example the bit fields in the registers, which are missing from the .h files provided by ST (they only declare the bits individually).
There are very interesting LL functions, for example to find many system frequencies. This can be done by tracing the system clock source, the PLL coefficients, then the divisors of the various buses. But it already exists and it's easy to use.
For peripherals like I2C the LL makes it easy to configure the CCR register. It is also easy to configure a UART, which is quite complicated in a recent MCU where each UART can have several clock sources (or only one!).
There are also failures, such as EXTI management.
For me the LL is a toolbox in which you can find interesting things to write your own drivers. The use of constants and LL functions makes it possible to self-document the code because the names are very explicit. And most of the time the LL is efficient.
The big question is why the HAL is not LL-based?
It's allowed to mix HAL and LL, then you get twice the same features!
The best way to debug software is to use it, and ST avoids doing that!
CMSIS are files related to the CORTEX-M core: https://developer.arm.com/tools-and-software/embedded/cmsis
Rest assured, many people develop themselves the API they need: it is more suited to their specific needs and more efficient. Reading the LL or HAL code often makes it possible to clear up obscure points in the documentation.
