In case you do calls to the engine, which cause an "asynchronous" task to be executed, the job-executor is used. In case the job-executor is quite busy, it can be that all threads in his/her pool are occupied. If this is the case, by default, the CALLING thread will be used to execute asynchronous activity. This will be the job-scheduling thread, effectively blocking any additional jobs from executing. This behaviour can be changed (see org.activiti.engine.impl.jobexecutor.RejectedJobsHandler and org.activiti.engine.impl.jobexecutor.CallerRunsRejectedJobsHandler).
I'm suspecting (judging from the numbers you're talking about) your job-executor pool is too small. Since the job-scheudling thread will be running a job, any new jobs added (by calls) will possibly be delayed (although not 100% certain about this, have been some changes in 5.14 in this area), explaining why the request are pending.
Consider sending emails in large batches (when you expect large quantities) instead of using one job for one email. In general, it's a good idea to use another system/service for sending emails and let the activities queue an email. So the external service can do the retry-ing and the async handling…