In a tight loop like this, I've never seen an example where bytesRead wouldn't always be equal to buffer.length, while the end of the file has not yet been reached.
When applied to reading a file on a local file system I agree. Although this may not apply to some of the old and slow CD drives etc.
And in any case where it does not, it's not clear that a BufferedInputStream would help.
In a tight loop like this and with a BufferedInputStream with the same buffer size as you are using then yes it is of no advantage and in fact it will probably just add overhead.
Where a BufferedInputStream has the advantage is when using a larger buffer size than would normally be filled by single a call to read(byte[])
Scrub that, I've just looked at the source code and basically a BufferedInputStream is just doing what you are doing by by calling read(byte[]). I had naively assumed it would pull some clever stunt like continuing to load data into the buffer on a background
thread so the buffer would be re-filled ready for the next read, but it doesn't.