Here is the way in which you should interpret the different symbols:
- $\widehat{\mathbf{i}}$ is the unit vector in the direction of relative motion (of the object relative to the mass of air).
- $\mathbf{n}$ is the unit outer normal to the spherical surface.
- $\widehat{\mathbf{t}}$ is the director vector of the tangential part of the traction vector, whose magnitude is $T_w$. That is, the tangential part of $\mathbf{\sigma} \cdot \mathbf{n}$, with $\mathbf{\sigma}$ the Cauchy stress tensor. Note that the tangential component of an arbitrary vector $\mathbf{v}$ can be calculated as $\mathbf{v}-\mathbf{n} \cdot \mathbf{v}$.
Notice that the first term is the projection along the direction of motion $\widehat{\mathbf{i}}$ of integral of the normal component of the traction vector (the pressure) over the sphere (the rest of components are zero (on average) due to symmetry). This is the pressure drag.
Similarly, the second term represents the integral of the remaining components, also projected along the direction of motion. This is the friction (or skin) drag, which is due to viscous friction.
As I pointed out in a comment, a real flow is assumed to be continuous and a continuum, and therefore in an infinitesimal sense, there are no discontinuities in a turbulent flow. Note -- even flows with shocks, in the infinitesimal sense, are continuous as viscosity works to smooth out the discontinuity at small enough scales. So, the discontinuities you point out are due to looking at the data at discrete times. Data from simulations or experiments are always discrete at some sampling rate, and so they may contain discontinuities. How sharp they are depends on how many cells (simulations) or sampling points (experiment) there are relative to the highest wavenumbers/frequencies in the flow.
However, your point then is still valid -- for simulations of turbulent flows, on discrete meshes, aren't the assumptions in the Taylor series approximations invalid? And the answer is yes, if your mesh is too coarse! In fact, if you have a numerical scheme with very little numerical dissipation and the grid is too coarse, you will get a buildup of error and eventually it may diverge precisely because the assumptions have been violated. Numerically, this can be treated by adding numerical viscosity, which will help damp down the accumulation of high wavenumber errors. These high wavenumber errors are due to the Taylor series approximation being truncated, due to random numerical errors due to finite precision math, and due to dispersive errors that occur when the mesh is too coarse to resolve the gradients accurately.
But also note that performing the Reynolds decomposition helps this quite a bit, and that's the inherent benefit in doing it to the equations. If you do the decomposition and only retain the equations for the mean $\langle U \rangle$, then the flow is very smooth -- there's no fluctuations at all! This lets you get away with a much coarser mesh without incurring numerical instabilities, although accuracy may still suffer. But, this means you need to model all of the effects of $u^\prime$ on the mean flow, so your overall accuracy is highly dependent on the quality of your model. This is usually called the Reynolds Averaged Navier Stokes, or RANS.
On another hand, you can apply a different type of filter in space such that you're filter sits somewhere in the inertial range, but not all the way up at the mean wavenumber/frequency. This is large eddy simulation, or LES. Here, you need more grid points because you need to resolve more wavenumbers accurately. But you don't need to resolve all of the wavenumbers because you still model some of them. There are far fewer wavenumbers modeled, so the model doesn't have as much of an impact on the solution as in the RANS case. Plus, since the model only includes parts of the flow in the inertial range, the model should be universal (if Kolmogorov was right that is).
So, the equations themselves are absolutely valid for turbulent flows, because the equations themselves are continuous. But, when simulating the flows or looking at experimental data, everything is discrete. And when it is discrete, there may be numerical problems introduced for rapidly changing variables if the discretization isn't fine enough to capture the changes. Decomposing the equations into fast and slow parts can relax those discretization requirements (for whatever definitions of fast and slow you want to choose).
Best Answer
The only way to determine the dynamics of the system (Newtonian fluid exerting a drag on a rigid object) in full generality, for all geometries and Reynolds numbers, is to solve the Navier-Stokes equations with the appropriate boundary conditions. These equations are at heart nothing more than local expressions for conservation of mass, momentum and energy underlying all of classical mechanics.
However, this is often more time-consuming than is warranted, since there exist far simpler expressions for drag that apply in certain geometrical and viscous limits. Even when your system does not precisely match the appropriate limiting conditions, you can often get a useful approximation by modeling your system as such. But if you need more accuracy, you can't avoid the full problem.
You've already mentioned one useful limit in your question. Another applies to the low-Reynolds number case, and is referred to as Stokes drag. Notice that in this case the drag is linearly proportional to the velocity, rather than proportional to the square of the velocity as in the high Reynolds number limit.
Given these two limits, one useful approach could be to write your drag force as $C_1 v$ + $C_2 v^2$ and then perform an empirical fit to find $C_1$ and $C_2$. You'll have to be careful, though, if you are working with non-steady flow, since $C_1$ and $C_2$ might then depend on time (note that this has already been pointed out in D.W.'s answer, but hopefully it is now more clear why this is often effective).
Caveat: If your fluid is non-Newtonian, then the situation can be even more complicated, since the simplest notion of viscous drag no longer applies.