The lock file was created by
process 1131 (packagekitd). It was created so that that process could make changes to the package system without worrying about other programs doing other changes at the same time.
If you remove the lock file, you make it possible for another process, such as
apt-get, to make changes simultaneously with
packagekitd. Since there was no lock file,
apt-get will also assume it is the only process making changes.
The result can be that some of the changes made by one process can be overwritten by the other. The end result will be some random mixture of the two change sets, which might result in a broken system.
It is possible to write programs so that they can work at the same time without stepping on each others toes, but it is difficult and can give some really obscure bugs. The authors of this package system decided it was better to just make a global lock file. This is simple and robust, but not very friendly to multi-taskers.
Now, all this assumes that
packagekitd is still running and doing things. If this process has in fact crashed without removing the lock file, the situation is different.
This might have left the system in a "halfway" state, but the package system is designed to detect and recover from that. (This is easier)
Rebooting is a very heavy-handed way of making sure that
packagekitd is not running anymore. During boot old lock files will be deleted since they can no longer be relevant.
If you are 100% sure the process has crashed, you can remove the lock file without rebooting. Use
psto check if process 1131 is still around.
If you are fairly certain the process is stuck somehow and will never end, you can
kill it safely. If you think it might be working as intended but just at an inconvenient time it is best to just wait until it is finished. If this is not possible, you can still kill it safely.