Ah, I see what you are getting at now.  With "equal" scaling on all axes, the [0,0.01] range is 1/100 the x scale.

The manner in which gnuplot works is that it centralizes the figure.  It isn't smart enough to know it could expand out the visual range and zoom a bit even if that means it has to offset (in this case) the y axis, whereas Qt toolkit at least makes better use of the screen area for the [0,1] range.  In other words, gnuplot is sort of an absolute relationship as far as the screen view, i.e., "scale: 1.00000, 1.00000", whereas Qt is more relative use of the screen view.

Does this seem like an Octave bug, or perhaps gnuplot?  We could attempt to compensate perhaps by generating a measure of

gnuplot_scale = min([ ...
  max([x_axis_range/y_axis_range y_axis_range/x_axis_range]) ...
  max([x_axis_range/z_axis_range z_axis_range/x_axis_range]) ...
  max([z_axis_range/y_axis_range y_axis_range/z_axis_range])];

or something similar.

I'm not following Dmitri.  Yes, some view point infinite in z might be shrinking the axis to 0, but is it something in the footer printout that seems unusual, or what is your train of thought?

Initially I was going to ask for a screen shot, but I see the issue.  As a slight aside, I know that gnuplot can do something like

linux@ ~ $ gnuplot

        G N U P L O T
        Version 5.3 patchlevel 0    last modified 2017-11-04

        Copyright (C) 1986-1993, 1998, 2004, 2007-2017
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        mailing list:     gnuplot-beta@lists.sourceforge.net
        faq, bugs, etc:   type "help FAQ"
        immediate help:   type "help"  (plot window: hit 'h')

Terminal type is now 'qt'
Options are '0 font "Sans,9"'
gnuplot> set view equal
gnuplot> splot sin(x+y)
gnuplot>

then use the center mouse button-click-drag left and right to change the scale.  So, in theory we should be able to adjust that.

But I look at the screen shot:

gnuplot_axis_equal_bug_Screenshot_from_2018-03-28_14-21-26.png

and I see in the footer that the scale is 1.0000, so this is nominal operating range.  The fact the plot is so tiny suggests that the border must be used up by something, be it a large title font, or large x/y/z label font.

That being said, the source of this problem seems more general than just gnuplot.  I'm also attaching the result of your command sequence for the Qt toolkit:

qt_opengl_axis_equal_bug_Screenshot_from_2018-03-28_14-23-21.png

Notice how it has the same issue, but perhaps not immediately obvious.  In the Qt OpenGL case, the z-axis looks to be scrunched to one pixel where the x and y-axis look reasonable.

As an observation, if for the gnuplot toolkit one uses that center-mouse-click-drag-left-or-right feature to zoom in on the axis equal plot, it looks similar to the Qt OpenGL plot where the x/y-axis is reasonable but the z-axis is still scrunched to a single pixel.

So at this point, I'd say there looks to be something generally wrong with the z-computation of the "axis equal" code.  As such, the category should be changed to just "Plotting".