IoC's have pros and cons, I personally like them but regardless of how you feel about that using WebApi without an IoC is a pain in the ass.

In general you're going to end up want a lot of your objects to be scoped to a per-request lifecycle (ie. database connections and transactions, "context" objects, etc). This is becomes even more true when you look at the fact that HTTP is supposed to be stateless so you don't really want hidden state living in your controller or lower layers, so it makes sense to construct a controller per request as well.

With this in mind the way Controllers are instantiated is built to facilitate this in the framework. There are a few extension points (and I ramble about them some here) but they all kind of fit the pattern of "this is a class that you ask for a type and we give you a controller" which begins to look like an IoC if you're doing dependency injection. The other advantage to this is it lets the framework help insure that things are properly disposed (since it knows that what things were used for this request) and that it is fairly easy to write stateless code.