A related issue is bug #53056.  In that bug report, the issue is that the linewidth expected by the glLineWidth call is measured in pixels, but the graphics property LineWidth is measured in points.  The conversion is

pixelwidth = Monitor_Pixels_Per_Inch / Points_Per_Inch * LineWidth_Points

Points_Per_Inch is a fixed constant of 72.  If we follow Matlab, then the Monitor_Pixels_Per_inch is always 96 and the overall factor is 96/72 == 4/3.

I don't fully understand all the implications of moving to a fixed PPI, however, so I can't recommend Octave do this until it is fully understood.

Copying a post from bug #45600:

Matlab seems to have adopted a fixed value of the "screenpixelsperinch" property (see [1]) for Windows and Mac platforms. Note that this makes this "pixels" unit device independent (an absolute unit).

The only reason I can see is Matlab has made the (unfortunate?) choice of fixing the default figure size in pixel units. Having pixels an absolute unit is thus a way to fix the absolute size of figures across different displays.
This also means that for ML compatibility we should follow the same route. Another good reason to do so is that, at least for Mac, Qt5 also chose device independent pixels [2].

The drawback of this approach is that it is not WYSIWYG: a figure onscreen will never have the expected physical size in inches (which is the default unit for "paperposition"). There are complaints about this regression on Matlabcentral [3].

Marking OS "any" even if on linux Matlab and Octave are compatible.

[1] https://fr.mathworks.com/help/matlab/ref/root-properties.html
[2] http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/
[3] https://fr.mathworks.com/matlabcentral/newsreader/view_thread/344106