No. If you look at an STM32 manual, they can be > 1k pages as you need that much information including the errata to truly use a part. MCUs with < 100 page manuals will rely on YOU finding the bugs and working around them.
Even with STM32, there are some peripherals that can be difficult to use without careful reference to the application notes, errata, and/or ST's sample code. The I2C peripheral on the STM32F1 is a prime example -- if you don't read/write certain registers in precisely the right order, the peripheral will lock up or return incorrect data.
On the whole, though, you're absolutely correct. :)
In further agreement, part of getting to know a new MCU is to breakdown your project into a series of small conformance test suites and at the same time, trying to get into the mind of the peripheral designers. Delays in config registers, changes not becoming visible until some other action. Weird interrupt behavior, timers, capture compare, reset, brown out, etc. They all have issues, and one can't just assume that _anything_ works. Everyone blinks and LED, sometimes multiple times on the same project. The firmware you use to debug the chip and the system is the stuff that keeps you sane.
Design systems for visibility and debugability. Multiple color leds, extra serial ports, extra flash to dump memory to, an external control MCU that can handle DFU, serial port access, monitoring, etc. Use the largest memory part that has the same pinout. Building a project that is going to ship qty < 100 with the smallest, most resource constrained parts is a foolish thing. Spend an extra $2 and get >256KB of ram. Get remote debugging working in the first week. Automate relentlessly.
