The hardware PWM (there are two channels) can certainly generate much higher frequencies (down to pulses a few tens of nanoseconds long). pigpio waves can work in that region (1µs resolution) and can keep count of the pulses transmitted if you use a wave chain. Have a look at http://abyz.me.uk/rpi/p...
The Pi's 5V supply is unregulated. Unless you have found a way to make it stable it will be going up and down. You also need to check if the output pin of the ADC is also at 5V - that could harm the Pi.
The pigpio daemon is software which runs on a Pi. It is a server running on the Pi. It allows access to that Pi's GPIO. The access is via TCP sockets (network or local) or via a pipe (local). The daemon is used by pigs and the python and pdif modules. See http://abyz.me.uk/rpi/pigpio/index.html
There are only a few Python libraries. See https://elinux.org/RPi_GPIO_Code_Samples The glaring omission is gpiozero which is a wrapper around the other libraries. Choose a library and spend time understanding what it does and how it works. If you do that you will have learnt enough to use any of th...
I would use (my) pigs to try out the commands. It allows you to issue commands from a shell and allows a quick test of what does and doesn't work. In practice a lot of chips do not actually need a restart condition to be sent on the line (and the drivers often automatically add a restart when needed).
I suggest you use (my) pigpio or servoblaster or RPIO.GPIO for servo pulses. They each use hardware timed pulses. Software timed pulses will be much more subject to jitter (which will shorten the servo's life).
I had a quick look at the posted code and it seemed to assume the Pi was local so results would be instant. The code I linked allows for communication delays by using a different feature of pigpio (alerts).