[merlight]

Adding delay is unnecessary, the move won't happen until your handler exists anyway.

Haven't really tested it, but I'm pretty sure the client doesn't do any network communication directly from API functions. Think about it - if you called RequestMoveItem and the client would immediately send the request to the server, waited for the response and then returned the result to you, the latency would be horrid, and your add-on would completely block all other add-ons for the duration of the request (by all other add-ons I mean the whole UI, health bars and such). API functions absolutely have to put network requests on a queue.

Then I have some design notes on your free slots caching:
1) You don't know in advance how many free slots you're going to need. Thus finding all of them before you start is a bit wasteful. The function I posted earlier looks for one free slot, you call it when you need one. This is a somewhat generic principle: don't search and cache everything you might need later, search and cache things you actually need.
2) Check whether a slot is empty using something other than GetItemName (comparing strings will always be slower than comparing numbers). I used GetItemType for that.
edit: 3) you probably wanted slotId_Bag = table.remove(LootManager.emptySlotsInBag); your code doesn't really take items from the cache, it uses the same 1-4 slots over and over.

From ESOUIDocumentationP5.txt (you can find it on official forums in PTS section)

* RequestMoveItem *protected* (*integer* _sourceBag_, *integer* _sourceSlot_, *integer* _destBag_, *integer* _destSlot_, *integer* _stackCount_)