This is solely due to the fact that BYOND has to ask the client if they have each file individually, queuing up the calls and going through them one by one. This adds quite a bit of delay in the process. So when you recursively call it more than a few times you'll end up blocking browse() calls and other things that wait for browse_rsc() for a very long time (upwards of 20 minutes on 500 files, equaling less than 500kb in size).
Being able to push a list of files through browse_rsc() eg
src << browse_rsc(list('file1.dmi','file2.dmi'),list("file1.png","file2.png"))
To send the whole list of resources at once, without all the back and forth asking if they have each file. It would still queue/block calls, but only until the client has verified it did its job (which shouldn't take nearly as long since it's not having to tell the server after each file).
In-flight browse_rsc() calls block browse() calls. /tg/station uses a queue of browse_rsc() calls to work around this. Unfortunately each browse_rsc() call involves a non-negligible round trip delay, and the status bar and mouse cursor flicker until the queue completes. We solved this by creating spritesheets which combine what were once hundreds of browse_rsc() calls into one. Unfortunately browse_rsc() can only export the first frame of a .dmi file, so we have to send every .dmi file through an external process which strips metadata and re-transmit it, losing the bandwidth savings of simple .rsc extraction.
There's maybe three or four places in that process that the pressure could be let off and everything would be good.