In particular, it’s the only way I’ve found to identify MyISAM implicit locks: MyISAM doesn’t support transactions, and prioritises updates over reads. To avoid inconsistent data, reads can cause implicit table locks.

Where this matters is a situation like the following:

SELECT * from bigTable WHERE (complicatedQueryConditions);
UPDATE bigTable SET someField=someField+1 WHERE id=1;

The SELECT will lock out the UPDATE until it finishes, and because updates are prioritised over reads and new selects will in turn be waiting for the UPDATE to finish.

If the SELECT takes eg 30 seconds, in effect every access to that table will be waiting on the SELECT. In such a situation, SHOW PROCESSLIST will be able to show you which query is not in a LOCKED state, and you can identify the evil query quite quickly.