Hi everyone! Wanted to share my related to the topic experience 
I also have had similar issues the OP described in the beginning. In my case, it was getting stuck on a BIOS POST procedure stage with code 33. But switching back to a normal boot after a couple or more restarts by a reset button. Time is passing by the problem is getting worse.
TL;DR
The BIOS SPI memory chip, following the ten years of everyday usage, became unreliable and started to forget time to time written bits. Flashing the chip with the same firmware multiple times in a row has helped the oldie hold its bits in the correct positions.
Not so long after I had discovered this nice topic I have ordered a CH341A programmer (for me, it was a black one) as it was recommended here. While it had been coming to me, I inspected the MB for any other possible issues. Including the voltage levels coming from the PSU and the VRMs on MB. And even their noise using an oscilloscope. Nothing wrong at that moment was revealed.
After the CH341A, including an onboard IC clip, came to me, I experimented with ways of connecting to the chip, avoiding its desoldering. And saw that the most stable sequence is:
1. Disconnect the 12V CPU power line, so the CPU won’t start after powering on. I believe the presence of peripheral devices, RAM modules, a VGA card, and even the CPU is not strongly required. But I had (and only) the CPU and single RAM stick inserted.
2. Attach the clip of the programmer to the chip. For less painful access to the BIOS chip, have before unscrewed the heatsink of the PCH chip.
3. Attach the PSU to a wall socket. One of the LEDs on the MB turns on with green light.
4. Attach the programmer to the USB port of another computer. The programmer’s power LED comes in with dimmed red.
5. Turn the MB power ON. And now, the programmer’s power LED runs bright red.
6. The connection to the BIOS chip is ready to be checked. Now, run the programmer software, the button “Detect” should be displaying active. By clicking on it, you will be offered a suggestion list and welcomed to choose the exact model of SPI chip. I had been experiencing all three variants and hadn’t seen any difference.
For the sake of checking the connection reliability, I read the firmware multiple times and saved the data each time in a different file. The resulted files were the same size, but their content slightly differs.
My first assumption was it the long unshielded clip harness is catching too much noise from the circuits around. Opening the files with a binary editor showed that the addresses of these “noisy” bits were the same in most readings. So I decided the memory chip got memory leakages.
If so, what the options I had:
1. Find a chip in a better condition, order it, then flash, check and solder it on the MB. Nor fast, either easy.
2. Just reflash the original that we already have. Fine, yeah. If it will, of course.
No, it won’t. After erasing, blanking, and flashing, the chip didn’t pass the verification stage. That shows the flashing data isn’t equal to the flashed one. It’s time to think more.
What if we try to fill those old flickering memory cells not just once but twice or even more, just for sure? Repeating the flashing stage only one more time, in my case, turned out enough.
So, how it goes: erase, blank, flash, flash again, now can verify and accept success. The sequence was applied a week ago. After that, the old chip began to give its content with no hesitations.
Fun fact. Avoid reflashing your BIOS in any standard manufacturer way since you will get the problems you had in the very beginning