Again, this might not be helpful.

A similar bug is found here:

Integrate[Boole[R > 1/(1/S + 1/T) > P],
 {T, -1, 1}, {R, -1, 1}, {P, -1, 1}, {S, -1, 1}]

It returns an expression numerically equal to 2.88629 - 6.28319 I. Since Boole[] has the value either 0 or 1, the integral cannot be complex. And substituting NIntegrate[] for Integrate[] yields the real part 2.88629. The complex value returned by Integrate[] is the same as the value used in constructing the PDF of the transformed distribution for NExpectation[]/Expectation[] in the OP's problem. Interestingly it's not the same expression, and FullSimplify[] cannot transform their difference into zero. Nonetheless, they agree to 100 digits. (Probably, if I looked up the right PolyLog identity, I could do the simplification by hand. But I don't see the point.)

Tools for workarounds

If this is important, here are some ways to figure out the integral being used and how to fix it. The fixes are ad hoc and require some preliminary work (such as verifying the correct PDF).

The following return the integrals used for NExpectation[] and Expectation[] respectively, wrapped in Hold[] so they do no evaluate. If they look good, you could use ReleaseHold[] to evaluate them. Otherwise you would want to fix them before evaluating them.

integralNExp = Trace[
  NExpectation[R \[Conditioned] R > 1/(1/S + 1/T) > P,
   {T \[Distributed] UniformDistribution[{-1, 1}], 
    R \[Distributed] UniformDistribution[{-1, 1}], 
    P \[Distributed] UniformDistribution[{-1, 1}], 
    S \[Distributed] UniformDistribution[{-1, 1}]}],
  i_NIntegrate :> Return[Hold[i], Trace],
  TraceInternal -> True]

integralExp = Trace[
  Expectation[R \[Conditioned] R > 1/(1/S + 1/T) > P,
   {T \[Distributed] UniformDistribution[{-1, 1}], 
    R \[Distributed] UniformDistribution[{-1, 1}], 
    P \[Distributed] UniformDistribution[{-1, 1}], 
    S \[Distributed] UniformDistribution[{-1, 1}]}],
  i_Integrate :> Return[Hold[i], Trace],
  TraceInternal -> True]

In the OP's case there is a term -8 I Pi that should be removed, which I do by replacing the complex number -8 I by 0. That this is valid was verified by the Integrate[]/NIntegrate[] computations discussed at the beginning of this reply.

Trace[
 NExpectation[R \[Conditioned] R > 1/(1/S + 1/T) > P,
  {T \[Distributed] UniformDistribution[{-1, 1}], 
   R \[Distributed] UniformDistribution[{-1, 1}], 
   P \[Distributed] UniformDistribution[{-1, 1}], 
   S \[Distributed] UniformDistribution[{-1, 1}]}],
 i_NIntegrate :> 
  Return[Hold[i] /. -8 I -> 0 // Echo // ReleaseHold, Trace],
 TraceInternal -> True]
(*  0.5000000106328868`  *)

This yields a convenient (?), 2.6MB (!!!) expression. Even though Echo[] reveals we zeroed out all the complex terms, Integrate[] gives us another complex result, just like with the first example above.

Trace[
 Expectation[R \[Conditioned] R > 1/(1/S + 1/T) > P,
  {T \[Distributed] UniformDistribution[{-1, 1}], 
   R \[Distributed] UniformDistribution[{-1, 1}], 
   P \[Distributed] UniformDistribution[{-1, 1}], 
   S \[Distributed] UniformDistribution[{-1, 1}]}],
 i_Integrate :> 
  Return[Hold[i] /. -8 I -> 0 // Echo // ReleaseHold, Trace],
 TraceInternal -> True]

N[%, 16]
(*  0.500000000000000 + 2.176903850077749 I  *)

The real part agrees with the NExpectation[]/NIntegrate[] result, so maybe it's correct.

I am using 14.0 and am still getting weird results. I tried with Expectation rather than NExpectation. Using Expectation eliminates the 'invalid input' but still gives a complex number. When I compute:

Expectation[
 R \[Conditioned] (P < 1/(1 + 1/T) && 
    1/(1 + 1/T) < R), {T \[Distributed] UniformDistribution[{-1, 1}], 
  R \[Distributed] UniformDistribution[{-1, 1}], 
  P \[Distributed] UniformDistribution[{-1, 1}], 
  S \[Distributed] UniformDistribution[{-1, 1}]}]

I get a real number. But when I compute:

Expectation[
 R \[Conditioned] 
  R > 1/(1/S + 1/T) > P, {T \[Distributed] 
   UniformDistribution[{-1, 1}], 
  R \[Distributed] UniformDistribution[{-1, 1}], 
  P \[Distributed] UniformDistribution[{-1, 1}], 
  S \[Distributed] UniformDistribution[{-1, 1}]}]

I get a complex number. The only difference is that the first condition has 1/(1+1/T) where the second condition has 1/(1/S+1/T). So something seems amiss.

I don't know if the following is any help:

This syntax seems valid (removing /T from first argument):

NExpectation[
 R \[Conditioned] R > 1/(1 + 1/S) > P,
 {T \[Distributed] UniformDistribution[{-1, 1}],
   R \[Distributed] UniformDistribution[{-1, 1}], 
  P \[Distributed] UniformDistribution[{-1, 1}], 
  S \[Distributed] UniformDistribution[{-1, 1}]}]

But the original throws an error. Maybe it's a bug?

Similarly this is accepted:

NExpectation[
 R \[Conditioned] R > T > S > P,
 {T \[Distributed] UniformDistribution[{-1, 1}], 
  R \[Distributed] UniformDistribution[{-1, 1}], 
  P \[Distributed] UniformDistribution[{-1, 1}], 
  S \[Distributed] UniformDistribution[{-1, 1}]}]

But this is not:

NExpectation[
 R \[Conditioned] R > S > P,
 {T \[Distributed] UniformDistribution[{-1, 1}], 
  R \[Distributed] UniformDistribution[{-1, 1}], 
  P \[Distributed] UniformDistribution[{-1, 1}], 
  S \[Distributed] UniformDistribution[{-1, 1}]}]

Perhaps there is a limitation on the number of variables that can be used in the first argument. Maybe the limitation is due to a bug?

I suggest reporting it to Wolfram. They may be able to help. If it is a bug, it needs to be fixed.

What about 13.2?
Screenshot:

IMHO version 13.2 is the most stable, tested and balanced of the most recent.

I tried your modification in versions 12.0, 14.0, 14.1 and they all give the same complex number. Any idea why (a<b<c) and c>b>a should give different answers?

@Denis's modification was to put parentheses around the condition. (I think.)

However, I, too, still get the "invalid input" error, which seems more significant than the complex number. Basic GIGO: You can't expect the output to make sense if the input does not.

Same here. I am not sure what the modifications are supposed to be. When I cut and paste the code, I get the same complex number.

Thank you!