I would like to preface my response with this "none of my suggestions are meant to help you not insult you"
form what you have said in your original post and subsequent replies I can narrow it down to three areas that could be responsible for what you are seeing.
One is your software, when you create your parameters for LPR you try to use a standard that is based a certain spec of camera. for example Panasonic face recognition is set to only process MJPEG images of 1280x960 @ 5FPS only. it doesn't matter if its a 4K 5FPS Panasonic camera the software is not going to work unless it has a stream with those parameters. I am not familiar with bosch but if it is a beefier camera stream than your software can handle, then to me that is not the camera manufacturer's fault but a limitation of your software, the camera is preforming as it is designed to.
the second is hardware, if your software is hardware limited ( as long as it has the hardware it can process anything.) and you are using 4K MJPEG images form the bosch camera and 720P MPJPEG from all the others you know that work it will take far more hardware to do so. So unless you are absolutely sure that the bosch camera is putting out MJPEG images as close as possible to your "known working cameras from other brands" then it could be that your hardware cant handle the extra work load.
the last is is of course human error, earlier you said you were trying to get a rtsp stream from the camera but gave a http URL. there is a huge differnce between a HTTP stream and a RTSP stream and how they are processed. HTTP streams will not drop packets and normally software will wait until all the packets have arrived and are sorted till they are processed. This will cause huge latency problems if you are using large amounts of packets ( like in 1,2,3+ MP camera streams) due to waiting for all of the packets to arrived and be sorted then processed not to mention that if any thing does get lost another request has to be made. A RTSP stream works similar but with one difference it transmits extra data along with the video, so if something goes missing it can drop those packets related to it so there is no bottleneck. there will be losses but that is preferred ( for live streaming video and voice/sound) over huge latency waiting for every packet to show up and get in order and then be processed.
but seems like bosch is willing to help you out i would take it as it can be a pain to shift though hundred of Dev pages for information sometimes to find what you are looking for.