Multiple requests are less efficient than sending large batches together.
To be the most efficient with large requests, every user of SolrJ UpdateRequest would need to write the same logic... Place adds into UpdateRequest until you hit the first non-add, then send the UpdateRequest and start writing your deletes until you hit a non-delete, then flush the UpdateRequest and keep adding your new transaction type until you hit the first ... In that case they should avoid using UpdateRequest altogether as calling the SolrServer directly is just as "easy." If we are going to batch on their behalf why wouldn't we do it correctly and be predictable with our ordering. I'm sure if JDBC batches did not maintain order, there would be havoc to pay...
Besides that, it isn't clear to users of UpdateRequest as to the order of operations, so someone doing an Add doc 1, Delete doc 1, Add doc 1 may not end up with the expected outcome. It turns into Add doc 1, Add doc 1, Delete doc1 when streaming and similary for XML version of the transaction. If I did a Delete Query : then Add doc1, Add doc 2 I end up with no docs as the delete query comes last, but I (the user) does not know that.
I've written code to work around UpdateRequest ordering and I usually end up only using it for commitWithin or having a commit tacked on the end of the request due to the above issues.