As many people have suggested, it is a question of convenience; but perhaps more profoundly, it is convention.
As a programmer, my first instinct would be to use a numeric key for a layer ID because that is the way it has always been done. Indeed, it may not even occur to me, on a conscious level at least, that I should do it any other way. Of course, if there is a technical reason not to use integers, say if there's a possibility of there being more layers than can be stored in 32-bits (a very unlikely proposition!), or if there is a business reason for it, then alternatives would be considered.
There are also algorithmic considerations with numeric keys. Sorting, and searching of a list of sorted values ultimately boils down to a comparison between two numbers, even if it is a list of strings or complex objects; they merely get turned into numbers with a hashing function. Having said that, on modern computers, searching a list of say 100 or even 1000 items is usually as quick with a brute-force approach as it is with a highly optimized algorithm. In the case of layers in a GIS, I can't see even the most complex of maps having more than 1000 or so, and even if it did, the other associated computations would take orders of magnitude longer than any small gain from an optimized search of a short list.
Integer keys "just make sense" to a programmer, and as Brad says, there is more effort in using non-numeric keys. Maybe not more code, but more mental effort, and we are lazy creatures of habit. Also, the key that uniquely identifies something like a layer in a GIS is considered "hidden" from the user, to make sure they don't mess about with it and break code that relies on its uniqueness (DB UNIQUE keywords notwithstanding). Because if you give a user enough rope, sooner or later someone will hang themselves with it. By all means enforce uniqueness on a user-editable field, but the underlying system must assume its key is unique and untampered with.