Blah, you wouldn't make anything super complex with these. Not something absolutely requiring debugging or emulation. Getting timings right by looking at the assembly listing would suffice as well.
Some IO expanding style things, some IO timing... Power up / reset sequencing control. Adding some simple states to otherwise analog discrete DC/DC converters. Possibly some kind of zero-crossing detection using the comparator in a polling loop, giving out a pulse, or a synchronized PWM. Adding some LED magic on an already existing bus (bit-banged). Things like that. Without all the modern genericity and library crap, something around 200-300 lines of C, possibly, typically. Probably not something with 10 parameters to adjust. Maybe one or two, with a few possible values. Something you have already tested before with reprogrammable devices. The small package is quick to desolder and replace a few times with hot air.
Given a somewhat experienced developer, you can prototype your idea on any microcontroller first, using the most basic peripherals available, then port/rewrite your code at once, giving some thought to it (i.e., being careful and using your brain instead of single stepping random crap code; even though isn't trendy in programming right now), and fix all the issues in a few iterations.
Actually, the longest MCU program I have written "at once", and which worked on the first try, without fixing anything, on the first flashing on an AVR, was around 200 lines of code and IIRC it did read a potentiometer through ADC for a "speed" setpoint and did some kind of 6-step commutation for a rotorless magnetic stirrer.
Granted, your first project ever on this part could be quite annoying. Writing code for any microcontroller the first time tends to involve "reverse-engineering" some peripheral usage due to poor documentation or just your own inattention in reading the documentation properly. There are always at least some small traps involved, requiring a few rounds of trial and error. But given the simplicity (i.e., lack of features) and small number of peripherals available, you would have learned everything in a few days. After that initial learning, given a simple project with finite specification that can be represented on a single sheet of state diagram (actually formally, or in your head), it's not going to require debugging or dozens of chips.
I have seriously considered parts like these. Will probably jump in one day (when I have the excuse, i.e., something that really needs using one of these). IMO, makes most sense when you use them more widely across different projects, because the most difficult part will be the first few days of learning. Then, you have unlocked another area of expertise you can utilize later! ... and put in your resume:
"Can design ultra low cost, super mass produced, almost Chinese toys".