(I think I will stop talking about Python and Lua now and focus on what I consider better options)
Since it was brought up, AngelScript's support for multi-threading is left to the application making use of it. You can have one instance per thread as in Lua. You can have one real thread manage multipe 'script threads' with custom cooperative or pre-emptive multithreading (an add-on is provided with the VM source code to help with thist). Finally, you can have one real thread per 'script thread'.
In terms of memory management, AngelScript is kind of like Python though from what I recall of the API for including Python scripts it gave the application less control. AngelScript allows the host application to tell it what functions to call to allocate and free memory (it defaults to the C Library's malloc and free). Objects are ref counted and it has garbage collection for detecting and dealing with circular references (which is very important, as you would otherwise have memory leaks; and the reason for using a scripting langauge is to avoid that). The collection process and be done incrementally (doing all a bit at a time), destroying all know circular referenced objects, and full cycle (for idle time only as it takes awhile). This allows the application stay reponsive and only stop to collect garbage when the time is right.
As I understand it, the garbage collecting is not thread safe even when AngelScript was configured at compile time to deal with multi-threading. That is why mentioning the threading stuff was important. With one script engine instance per thread, it is not a problem as GC is done on a per engine basis. With the other threading models you control threading and GC therefore you can decide how to deal with this.
AngelScript is made to be embedded in an application and interfaces well with C/C++ modules. All the work is done on the application / native module side, which is more likely to be done by people with better programming skills. This is mainly registering functions, objects, and classes with some work being needed for calling scripts (scripts call native functions the same way you would another function in the script). The types used are the same the application/module uses so there is no conversion needed.
Calling scripts requires more work for native code, but that is generally the case when passing arbitrary data to a function wherever it comes from. As far as I can tell, the application can call the functions registered with the script engine the same way it could functions from scripts [Edit: You can call functions registered with AngelScript the same way as you do the scripts]. This would save the trouble of devising a way to pass arbitrary data to the functions (which is a must when what data is being passed is decided at run-time).
You can see a list of features at: http://www.angelcode.com/angelscript/features.asp