Well once the framework is open-sourced, we can take a look at exactly where .NET calls out to AMSI. The API for AMSI isn't super magical, there's simply a way for an interpreter/runtime (like PowerShell or .NET) to call out to an IAMSIProvider to scan an AMSIStream* (basically a buffer). The provider can be hinted whether to consider this buffer a part of an overall session, or as a separate session. The idea being that malware that attempts to load or eval bits and pieces accumulate into the same stream and that gives a scanner a better chance of seeing the whole thing.
This is primarily a way to make fileless malware more scannable. The AMSI API doesn't really provide a way to provide more introspection into what the process is doing.
Right now it seems like the AMSI hooks are literally just on Assembly.Load with a byte array, as a way to scan .NET assemblies that aren't loaded from DLLs on disk. I mean I suppose if one were crazy enough to run a .NET service that takes in user/network input and then attempts to Assembly.Load() it as a byte array, this can stop that sort of attack, but that's a bit far fetched.
Don't get me wrong, I think it's good that AMSI is being introduced in more places. But overall the protection this provides is really minimal. AMSI is great for detecting hollow things like PowerShell, cmd.exe, or other always-available interpreters from being used to load KNOWN malware from network directly into memory. But nothing that ships with Windows uses .NET and assembly loading into memory in this manner, so it's unclear to me what kind of attack this was supposed to prevent.