The issue with high tick rates isn’t that FreeRTOS itself has problems, but that running the tick at a high frequency means the tick interrupt and the scheduler get run often, and use up significant CPU resources, and at some point, they will use up all the CPU time so nothing is left to run your program. What does have a problem are some of the ‘convenience’ macros that convert time periods to ticks, those don’t work right if your tick period isn’t an integral number of milliseconds.
Another point, you DON’T need a wait for 33 micro-seconds, but a wait to the next 100 micro-second period, so you just need a 10 kHz rate timer. In FreeRTOS, delays are always relative to the timer, so a delay of 1 tick means delay until the next tick interrupt, which might be almost no time.
10 kHz is a bit fast in my opinion for the FreeRTOS tick but maybe doable if the processor is running reasonably fast. My thought of using a simple hardware timer to trigger the ADC converter is that this would make the sampling period very accurate, and in most systems using a high-frequency sampling, keeping the period accurate is important for accurate data. Working off the tick interrupt and such is apt to introduce a bit of variation into the timing.