A PIC would be preferable to the other circuits offered because of the flexibility - the ease of rebuilding and changing many parametrs and doing it easily.
That assumes an experienced level of programming skill, one that can structure the code such that the many parameters are easy to alter. Again, this is *way* outside the OP's skill set, not even counting having to learn C in the first place.
You're rather assuming he's experienced at building electronic circuits?,
No, I'm explicitly not. I estimated it would take him 2 hours to wire the circuit on perf board because I remember how long it took me to wire my first perf-board circuit. And, as above, you are assuming the OP is a C savant, able to write structured, configurable code right out of the gate. I also remember how long it took to sort out the I/O port configuration registers on my first PIC project.
And, let's not forget that a PIC-based circuit is still a circuit. 50% of the time it would take to complete the #9 circuit construction still is needed for a PIC circuit - acquiring, measuring, and cutting the perf board, wiring the connector(s) or power and I/O wires, mounting the switch, and soldering wires to the PIC pins and decoupling cap. That leaves less than one hour of wiring as the delta between the two circuits. Do you really think that cranking up a first-ever embedded controller project from scratch is less effort, less cost, or has a higher chance of initial success?
And, since the controller approach has two very different things (hardware and software) that can be wrong and need debugging, as opposed to the circuit in #9 (hardware-only), which approach do you think would be easier for the OP to debug? How long do you think it would take him to figure out where the problem is in a controller project, the software or the circuit? Note that in the #9 circuit, the Q14 output is running at 0.25 Hz. That's 2 seconds up and 2 seconds down, plenty slow enough to see sign a DMM and determine if the oscillator is running correctly.
ak