Logic equivalence check is normally carried out to ensure some processing of the design (example logic synthesis) has not resulted in change of functionality. It flags any logical changes with respect to a golden set of collaterals. There are many applications of logic equivalence checking, some of the prevalent ones pertaining to:
1. Logic equivalence check between RTL and corresponding synthesized netlist to ensure the logic synthesis has not introduced any functional issues
2. Logic equivalence check between two sets of netlists after doing netlist edits.
One thing to note here is that since RTL is the starting point here, LEC is done only for the logic present in the RTL, even for netlist vs netlist LEC (exceptions can be there). Other logic, such as scan chains are bypassed by application of certain constraints during LEC. For such logic, there are other methods to ensure correctness, such as scan tracing check to ensure there are no unintentional issues to trace scan chains.
Insertion of lockup latch also falls under non-functional netlist edits, hence not covered under LEC in normal scenarios. We must observe that fanout if lockup latch goes to scan_in pin of flop, which is not checked under LEC.