Solutions returned by Solve are provided as Rules:

    solnRule1 = 
      y -> 1/(3 (1 + x)) - (-1 + 2 x)/(6 (1 - x + x^2)) + 2/(
        3 (1 + 1/3 (-1 + 2 x)^2));

Solutions returned by Reduce are provided as equations:

    solnEqn1 = 
      y == 1/(3 (1 + x)) - (-1 + 2 x)/(6 (1 - x + x^2)) + 2/(
        3 (1 + 1/3 (-1 + 2 x)^2));

It is my understanding that Simplify's standard behavior is to treat both of these the same:

    Simplify@solnRule1
    Simplify@solnEqn1

[![enter image description here][1]][1]

However, that is not the case for these identical solutions:

     solnRule2 = 
      y -> -((-10 cF Ee F Log[10] + 10 cF Epzc F Log[10] - 
         23 cF pH R T Log[10] + 23 cF pKa R T Log[10] + 
         23 cF R T Log[f/(1 - f)])/(10 F Log[10]));
     solnEqn2 = 
      y == -((-10 cF Ee F Log[10] + 10 cF Epzc F Log[10] - 
         23 cF pH R T Log[10] + 23 cF pKa R T Log[10] + 
         23 cF R T Log[f/(1 - f)])/(10 F Log[10]));


When Simplify is applied to the rule-based version of the above solution, it acts normally:

    Simplify@solnRule2

[![enter image description here][2]][2]

But when Simplify is applied to the equation-based version, it equates the solution to zero:

    Simplify@solnEqn2

[![enter image description here][3]][3]

I don't know why Simplify is doing this.  When I convert solnEqn2 to a rule-based format, it behaves normally:

    ToRules@solnEqn2
    Simplify@%

[![enter image description here][4]][4]

This can cause problems when applying Simplify to the output of Reduce:  Reduce can provide solutions to several different variables, and when one solution is equated to zero it can be difficult to determine the variable it represents.


  [1]: https://i.sstatic.net/mSKBn.png
  [2]: https://i.sstatic.net/EcEm0.png
  [3]: https://i.sstatic.net/7KiY4.png
  [4]: https://i.sstatic.net/vqcrl.png