Well, I disagree here. The Oversampling class is doing exactly what its name says : oversampling.
The reason why the function Oversampling::getLatencyInSamples() doesn’t return an integer value is because most of the filters that can be used inside introduce a not integer latency, and it’s a way to say that it’s up to the developer to deal with it. It’s also a reminder that using IIR filters (with the polyphase allpass filters) does introduce latency in contrary to a myth that was caused by the massive use of well known c++ files that are still available on music-dsp.com, even if doing so is called the “minimum-phase” approach. And even if all the filters are FIR linear phase, the additional resulting latency could be not integer as well, because of the oversampling factor dividers.
So what should be done now that we know the latency is not integer ? Obviously we see that having a dsp::Delay class would be useful. Not only to compensate the extra fractional delay, since the DAWs expect integer latencies in the API and for any parallel processing to work properly, but also to implement internal dry/wet in a plug-in if needed. And it’s not here so it’s up to you to code one in the mean time.
Another thing which could be a temporary solution, is to make your own custom Oversampling class, which herits from the original, so you can change the filter initialisation in the constructor and choose designs which return an integer additional latency, by tweaking the filter design methods arguments until (std::abs(latency - round(latency)) < epsilon).
One other thing I would like to say is that dealing with fractional delays properly is not as easy as it sounds. If you don’t want your code to introduce additional lowpass filtering, that could be very noticeable, you have to forget about FIR polynomial interpolators (linear and Lagrange) and use IIR instead (CatmullRom, Allpass, Thiran etc.). Polynomial interpolators is a very interesting area and not that well known. Moreover, most of the documentation about it is quite confusing, or even misleading (Dattor… cough).
So now, what I can tell you is that the JUCE team is well aware of these issues, and that I have already some classes in my base code to deal with all of that, but there were some limits to what could be included in the first iterations of the DSP module otherwise the deadline would have never existed. And you’ll see other iterations in the future for sure ! We have already a lot of ideas, but I’m not in position to talk for the JUCE team about that, since I’m a freelance 
And before that, I’m afraid you have to rely on your own delay code or on custom Oversampling classes to deal with all the issues. I don’t think most of the people interested in the oversampling class don’t have already their own delay class anyway. And as I said, having simply an additional fractional delay in the oversampling class would be a temporary solution since some delay is necessary when parallel paths are available in the plug-in itself. What I can say for now is that the choice of the designs in the original oversampling class are not that random, and for most of the uses it’s fine to use it as it is and to add a round(latency) where you need to report latency to the host. For doing a better job, the only solution I would find acceptable would be to have a proper dsp::Delay class.
