I think HAL's are also a way to lure beginners and intermediaries to a vendor lock in.
If you look at hardware on a RTL level, then most operate almost identically. Where each bit is implementation details. Virtually any peripheral is structured the same: control registers, status registers, interrupt status/clear flag registers, and some data and auxillary registers.. for many many peripherals.
If I need to set up something new, I just set everything to zero and begin bringing in the stuff I need 1 by 1. That often works pretty well. Sometimes I will need to read some software description manual, e.g. how to set up the correct interrupts, DMA channels, FIFO's, initialization locks and delays, etc. But those are again implementation details..
Imagine if the manufacturer writes their HAL wrapper around it and immensely invest into frameworks, code generators, etc. Whoila you have an eco-system that should be great beginners or to get something done quickly (if there are no quirks and bugs, of course).
The problem is:
A) Eco-system is synonym a prison, especially in the enterprise world.
B) Backporting new HALs and frameworks could be a mess if the mfgr doesn't care about breaking changes
In software dev world you would seriously consider each dependency you add to a project, for the same reason as B, but also potentially if the project gets shitcanned by a company or OSS community and you're stuck with a soon-to-be outdated dependency.
Now in embedded this is often less of a problem. Many projects used a custom design/MCU. If the code works and is done (no more feature development), then eventually enough bugs have been squashed and in a few years time, the project has become 'legacy'.
Concerning point A): manufacturers will never have an interest in developing a compatible API of peripherals between devices. That's not an imprisonment for their customers, and so in the chance of e.g. a huge chip shortage it would be too easy/cheap for a customer to run to NXP/Microchip/SiLabs/etc. In contrast, ecosystems like Arduino, mbed, etc. are the closest to succeed in "compatible" APIs, however, but in those paradigms you will need to look up which ports have been assigned for various functions. E.g. on Arduino: which timer is used for ms timebase? Which serial port is reserved for using the bootloader and the default Serial object? Which I2C peripheral is used for the default Wire object? Which GPIOs are assigned to which analog/digital pinout on the original Arduino Uno form factor? And what if they conflict with an 'alternate' peripheral you need? Bad luck?
Now IMO ecosystems like Arduino are still some kind of imprisonment. Similar to how you can see many people ask about to use STM32 HAL's, or change over to a different chip/brand, etc. You see the similar thing happen for people moving away from Arduino. I get why it's attractive to use these paradigms to start learning or get something done (as I occasionally also do for quick projects), but in terms of control I think ecosystems will never deliver.