File locking reserves a file so that one person at a time can edit it. On a project full of unmergeable binaries it is the primary mechanism for not losing work, because it converts a problem you cannot solve after the fact into a question you answer before starting.
The workflow is short. Lock the file before you open it. Edit. Commit, which releases the lock. Anyone who reaches for the same file while you hold it is told who has it, and can pick up something else instead of building work they will have to discard.
What to lock in an Unreal project: Blueprints, levels, materials and material instances, animation Blueprints, and any DCC source file two people might touch. What generally does not need locking: config .ini files and C++ source, both of which are text and merge normally.
A common misconception in Unreal Engine 5 is that One File Per Actor made locking unnecessary. It did not. OFPA removed the level-file bottleneck so that people working on different actors no longer block each other, but each actor file is still a binary .uasset, and Blueprints and shared materials were never covered by it at all. What changed is the probability of collision, which paradoxically makes the remaining collisions more dangerous because teams stop expecting them.
USourceControl locks are server-authoritative and per file, so they cannot be bypassed by a misconfigured client, and locking one asset never freezes the rest of the project.