Also note the huge difference between:
* Classic STM32 "Standard peripheral library".
This is now officially obsolete, good riddance. A few years ago we had the same fight on these forums about this, you were told you absolutely must use this horrible piece of crap otherwise you are "wasting time" and being generally stupid. Then ST made this obsolete overnight, now even Good People are not supposed to use this. This sudden attitude change (while technically nothing changed) is the testament of the cargo cult engineering attitudes, all driven by opinionated feelings, not facts.
But most of the STM32 examples online use this library. In reality, this library is an utter disaster, because it does not abstract anything at all, but only adds a layer of extra boilerplate for no benefits whatsoever. 1 LoC initialization becomes unwritable 20 LoC which is either copy-pasted or autogenerated, and you still need to know what every configuration bit does because they map almost 1:1 (but not exactly, for maximum confusion).
* STM32 HAL
What a horrible name. Protip: when coining a proper noun, just don't use the well-known name of the concept. For example, if you want to establish a grocery store, don't call it "Grocery store", communication will be difficult. Similarly, when coming up with a specific HAL library, don't call it HAL.
This naming thing out of the way, STM32 HAL makes perfect sense because it abstracts. It's successful in this regard, and no one questions that. That's really the argument to use it. Because it abstracts, it hides unnecessary burden from the programmer - in theory. Also because it abstracts, it can make code portable across different devices - in theory. Finally, because it abstracts, it saves time - in theory.
Now all that is left is to answer the questions:
* Which STM32 peripherals benefit from being abstracted to a linked library at all?
* Which STM32 peripherals benefit from having a manufacturer-implemented generic abstraction instead of rolling your own?
* What does "benefit" mean? Just time saving, or maybe performance, code size, maintainability? Being able to do what is needed at all?
* Is STM32 HAL well implemented?
* Is STM32 HAL really portable?
* Does STM32 HAL really save time in the big picture?
... and so on.
But people like dietert1 can not discuss such points, they can only come up with very simplistic strawmen and attack those in some one-liners. But this is unsurprising; if you don't have such thinking capabilities, being able to program will be difficult, too, and all that's left is to try random oneliners in the hope that they happen to work. HAL is agreeably great for that, and possibly even successful, assuming you never hit complex requirements but instead build "typical" projects for which the HAL was written and tested, like "replicating" devkit projects.
One of the stupidest strawmen arguments is "oh, why would you implement identical generic library yourself, you must be stupid". Of course you won't, if you think something sucks then obviously you won't replicate it, but do something different. In this case, designing a generic abstraction layer for something that have tens of thousands or millions of functional permutations, there are two approaches:
* Reduce the available functionality, i.e., artificial limitations on what you can do,
* Make the abstraction layer complex, difficult to use, and the implementation thereof difficult to write, bloated and slow, to support all available functionality.
In reality it's a mix of the two. Thankfully STM32 HAL emphasises the former, otherwise it would be even more bloated and not easy to use. (The SPL was an example of the latter.)
You can sidestep this issue completely when writing your own abstraction (or in simplest cases, not abstract at all) in per-project basis, and this is where the time saving lies. Maybe it takes 10 minutes to write UART init and simple TX/RX functions using the HAL, and maybe it took 1 week for ST to implement that part of the HAL. But this doesn't mean it takes 1 week to do it without their HAL, no, it takes like 20 minutes, completely insignificant.
Also no one's saying you shouldn't use libraries ever, at all. Don't write a TCP/IP stack. Use existing code or libraries when they actually save time and/or improve the code quality. This shouldn't be cargo cult engineering, we can do educated choices based on facts!