I can confirm that it is Octave postprocessing of the edges that is the problem. Unfortunately, I'm not sure I have a solutioncomputational geometry is not my area of expertise so I don't understand particularly how to replace the algorithm we have with a better one.
This could go on to the Bugs or Projects List and maybe we could enlist some outside help. You might also put in a request on the OctaveMaintainer's list to see if there is someone with the requisite knowledge to look at this report.

As I understand it, Matlab still uses QHull. It just doesn't expose the API to programmers anymore. With Matlab, you are stuck using whatever options they think are appropriate.
But, I don't think this is a problem with the QHull library. The voronoi function in voronoi.m does postprocessing on the edges found. I think there may be an issue there. The code is
If I change the factor from 1.1 to 100.1 then I get a figure equivalent to Matlab. If I comment out the code completely I get an en equivalent figure as well.

Actually, this was part of the larger dataset
with which you get some edges, but last three points are hanging in the air, instead I would expect to have parallel edges separating them.
Tried my first example in Matlab Live editor and it failed saying that points are collinear, but this second one works fine showing parallel lines for last four points, while in Octave they are absent.
(file #45293, file #45294)

I think this is an invalid input (what kind of voronoi cell would you expect from collinear points?) and voronoin fails as I would expect:
Probably the only bug here is that voronoi fails silently instead of firing an explicit error.
