The second binding will probably perform marginally better, because WPF does not need to traverse the lengthy property path, but it has different semantics. In the first binding, if any of PropertyOnObject, Property1, Property2 or Value changes, the binding will be re-evaluated. In the second binding, the property chain will be resolved when Source is set, and the binding source will be whatever Property2 was at that time. So if (say) Property1 changes to refer to a different entity, that won't update the binding, because the binding is attached to the Property2 object independently of the reference chain. Only if you change the value on the original Property2 object will be binding update.
Since you want the first behaviour, you need to write the first binding, and pay the minor performance penalty. Writing it the second way may be faster but will give you wrong results.
Note that the performance penalty is going to be insignificant unless you have a huge number of these bindings: you're operating on a UI timescale here, so a couple of milliseconds here or there just doesn't matter. Don't try to optimise the binding unless you can establish that it really is causing a problem.