The issues here are not so much security wise (that's downstream of this topic) but pragmatism. The penguin problem rules out ECB mode for most cipher use, so lets look at your requirements:-
Divide data into n parts
The easy bit
Run n threads
Not as easy as it sounds. This is very language dependent. For example Python doesn't do well with parallel tasks due to it's global interpreter locking system. Java threads can be cumbersome. And then there is the inter-thread communication - more overhead and slowdown. Even C/C++ threads will have to talk amongst themselves. Will you write a thread pool yourself? I guess there must be an extant library you could use as mitigation.
Each thread encrypts its part of the data
The crux of the cryptography. Have a close look through the wiki entry on cipher modes. You cannot hope to achieve parallel operation on all modes as that's fundamentally impossible for some as they're sequential. CBC mode is a simple example of one ciphertext passing into another subsequent block operation. Yes it can be run with multiple threads, but each thread will be paused waiting for the previous one in the chain to complete. That said, CTR mode seems to be a mode that's suitable for your scheme.
Take the output of all of the threads and concatenate (join) all of them together
Even in CTR mode the chunks have to come out in the correct order, requiring more thread collaboration. And again inter process communication has to be addressed which will siphon off speed gains.
So in conclusion, and without even dealing with specific security problems, this scheme is troublesome. Since only a few modes are possible in this scenario, and their security issues are mode dependent, it is quite difficult to give more detail. But just to mention a generic one, clones of the key and plaintexts will be floating around the machine that might open an attack vector. And the time of complete thread destruction can be uncertain under a garbage collector.
This falls into the realm of writing your own crypto, with key management, inter process communication and a large case of debugging. With modern CPUs featuring hardware AES circuity, that is clearly the way forward. I cannot think of any circumstance that warrants this level of cryptographic development, testing (heartache) and security risk. Remember that time is money if this is a commercial venture, and in that case does dubitable and possibly marginal performance gains offset just getting a faster CPU?