Explanation of the EPC Gen2 randomness standard's first rule When we read PRNG requirements of the EPC standard, first rule (page 57 in this link) in the documentation;


  Probability of a single RN16: The probability that any RN16 drawn from
  the RNG has value RN16 = j, for any j, shall be bounded by 0.8/2^16 &lt;
  P(RN16 = j) &lt; 1.25/2^16.


Does that mean if the PRNG generates 2^16 16-bit numbers, each number should occur once? Basically it wants a perfect 16-bit entropy.

But if it is this way, even C#'s cryptographically secure PRNG cannot meet that requirement. So I'm wondering that I interpreted this requirement right.
All is revealed in the last paragraph of that section, repeated below:-


  A cryptographic suite defines RNG requirements and randomness criteria for cryptographic operations. These requirements and criteria may be different, and in particular may be more stringent, than those defined above for inventory and password operations. 


Their three randomness tests are an attempt to create a protocol that works in the real world without too much computational effort.  By crude analogy, it's like a children's test for randomness.  You only have 65536 possible choices anyway (assuming the RNG can reach them all), so there's little point in relying on huge computational effort to generate cryptographic strength Tag codes.  An attacker will just brute force them when appropriate tools are developed.


  Basically it wants a perfect 16-bit entropy.


Actually no. On this forum, entropy is defined as unpredictability within a certain system's defined scope.  There's a EPCglobal test that stipulates that sequential values are only 0.025% certain.  That's pretty poor to protect your bank account or nuclear arsenal.  For perfect entropy, the next value should only be predictable with a 0.0015% certainly, irrespective of prior RN16s.   The first rule is just a lax, perhaps pragmatic interpretation. It allows a ~22% bias in the numbers. 
 And yes, that means you can have consecutive identical RN16's.  Prolonged consecutive RN16s might be an issue for the specific protocol implementation (I don't know).


  C#'s cryptographically secure PRNG cannot meet that requirement


Unfamiliar with C#, but if it's like a proper *nix language, then the cryptographic generator should be pretty good.  My interpretation of these rules is that they are much less stringent than those required for cryptographic purposes.  Thus C# might very well fail them in the strict technical sense.  It's just that C# is too good for them.  True randomness (opposite of bad randomness) is a slippery beast.  (It might be useful to flesh out your question illustrating how C# fails the tests). 

You don't have these three rules in cryptographic RNDs.  Just that each byte is very exactly 1/256ths certain in the long run.