The purpose is it allows BF programming to emulate a file lock and is a significant design improvement from legacy programming. During journal printing / updating at least, the CreateLock function is called and it creates the 0 byte .LCK file and physically locks it instead of locking the data file. This allows other MAS processes to know an update is in progress. When the journal update is complete, it unlocks the LCK file but not sure if it deletes it. There's no problem if you delete it yourself and if you don't delete, still no problem.
In legacy when a file was locked during printing / updating of a journal, the actual LOCK command in ProvideX was used and this produced a real physical file lock on the actual data file and interfered. It was one of the causes of ""Table is not accessible"" when using ODBC to read records from a report or a business alert.
Hope that helps.