Feeding ES directly - Is a queue needed?
I am new here, but I will try to share my own experience with ES.
Here, we are using couchDB to store the json we are indexing into ES. However, we do heavy modifications on those docs, like creating new nodes, etc etc. The docs are big, hundreds of fields, more than 15 nested collections.
Finally, there are thousands of docs.
So, yes, in my humble opinion, if you can create your docs via your application, I do not see why ES would have trouble with that.
For the python part, though, I cannot help, we're doing things in java, here.
However, for ES, I would 

use the bulk api. ES is (much, much) more efficient that way. 
I'd probably store the ids of the docs that couldn't be indexed due to random errors in another index (or in a file, or somewhere else) so that you can reconstruct and reindex them afterward, instead of a retry on error. (Though I couldn't know about the feasibility in python)
not use a replica for an index currently indexing.

For the retry on errors, I have mixed feelings. If the error is due to a wrong construction of the doc or to a mapping error, it will fail on each retry.
Here, we are indexing thousands of those docs a minute, and still can issue search and facet requests (those could be slightly slower, though). 
This is not much, but I hope it helps.
Good luck.
I am looking at the possibility of using ES without a database, constructing my data from my python application and sending it straight to ES in real time. It says me a lot of complexity, however my concern is that I might be generating data very quickly and sending requests relentlessly, even when ES might not be ready to accept it. 
My question is, in this case does it makes sense to use a queue system as a buffer between the two, so my application sends everything to a queue, and then queue tries to add it to ES, retrying if it doesn't have success. 
I am not sure if this is the most logical or efficient method. If anyone has any information or ideas on what queue systems would be suited, or if I even need one, I'd be very interested to hear. 
James