The “non-responsive” one explicitly sets the height and width to 25.4mm (1 inch) whereas the “responsive” one doesn’t set the height and width at all. So it’s no surprise that the GFUI doesn’t know how big the responsive one should be.
All the other measurements in the file are in user units (bare numbers with no explicit units attached), which have no fixed mapping to real life units if the <svg> element doesn’t have an explicit size set. In that case the GFUI has to just guess, and I think it uses 96 user units per inch if the file doesn’t specify. (And because 72 is 3/4 of 96, you see 75% scaling as a result.)
Any SVG file needs to use real units (e.g., mm or in) throughout or it needs to establish the size of user units by setting the height/width on the outermost <svg> element. Any file which fails to do so is going to show up as different sizes in different programs, depending on what assumptions the individual program makes as to the size of user units. (Adobe uses 72 per inch, Inkscape and GlowForge use 96 per inch, etc.)
I figured out the same when trying to debug the problem. I almost fell into the trap of relentlessly pursuing a fix for the DPI in illustrator when I realized that the problem simply solved itself by not checking the box.
Old habit from day job. Exporting as SVG strips out all illustrator specific metadata, resulting in a smaller file size. If Autodesk or Glowforge are dependent on that metadata, that would be the reason for issues on import.
Since the manual has no recommendations on working with Illustrator, I just went with what I knew. I haven’t had any other problems with Exporting as SVG, but it looks like I may need to change that