That basically ignores the pixels/inch spec, then, which I don’t think happens. For example, if your image is 100 pixels wide at 72 dpi, and you change the printer spec to 144 dpi without changing the number of pixels in the image, then your image will print twice as small, because it’s “fitting” more pixels into an inch (144 of 'em instead of 72), and there are no additional pixels in your image without resampling. Resampling creates new pixels so the image “fills out” the print area, but then it’s not exactly the same image as you started with, it’s been “reinterpreted” at a different size with more pixels. The d-box shown has a choice of “Interpolation” mode – that’s the algorithm used for resampling. Looks like Gimp automatically resamples.
In Photoshop you have the option to not resample, which gives greater flexibility in matching rendering resoluton (pixel dimensions) to printout size (based on the pixels/inch or cm spec).
True but that particular “pixels/inch” spec is completely irrelevant in terms of printing – it’s only the monitor’s rez, not the printer’s. What is important is the total number of pixels in the width/depth of the image, because you can specify how many pixels/inch (or cm) your printer works at. Obviously more pixels will give better image quality, and “downsampling” is fine (that’s what you describe by upping the Blender pixel dimensions and reducing the print scale), it’s done quite often in the printing industry.
I think what it boils down to is we’re both talking about doing very similar things, the diff being that by setting up both print app and Blender in advance so the units all match up, there’s no need to do anything but model & print, no need to re-spec the dpi (other than initially), render larger than needed, or do any other massaging, the setup takes care of it all in advance. I’m sure your method works just as well, but maybe with more steps.
EDIT: Completely ignorable historical sidebar 
The “300 dpi” default that many printers (both desktop and offset) use is a leftover from the early days of digital image processing for print. At that time, it was standard practice to convert the digital files (composed of pixels) to halftone images on negative film (composed of various-sized dots when printed), and then printing plates were exposed as usual and offset printing proceeded. It was soon discovered that for best image quality on the printed page (using the software and technology of the time), it was best to have two pixels in the digital file for every “dot” on the halftone image. Since most halftone images were printed at “150 lines per inch” (“lines” being the term for the halftone dot – confusing, eh!), that meant that digital images should be at least 300 dpi (actually meaning pixels/inch, not “dots”) for highest quality offset reproduction.
But that 300 dpi refers to the resolution at the size the image is being printed – it’s a relative measure, not a constant inherent in the file. A file 8000 pixels wide at “72dpi” will print just fine at “300dpi” without resampling, just at a smaller print area size. The “dpi” spec just ties the otherwise dimensionless pixels to a real-world dimension, and it can vary as needed for any particular printing need.
Modern printing and other reproduction tech doesn’t require that same “300 dpi” standard, because the software that converts digital files to offset dots has gotten much better – in some cases, the halftone is dispensed with entirely (called “stochastic” printing). Digital files can now be transferred directly to printing plates without the film intermediates once required. And many ink-jet-type printing processes (such as your desktop printer) cannot use the “300 dpi” standard – they are more likely to output at 100-150 dpi max resolution, which is just fine for most any but the more critical printing requirements. Most of the vendors I worked with who used inkjet processes for banners and large signage worked very comfortably with 100 dpi files, and the results looked great.
Upshot is that it’s OK to overdo the number of pixels in a rendering, though it adds rendering time, and then “downsample” for the type of printing being done. Better yet imo to tailor the rendering size to the real-world need --saves render time and requires fewer steps in the long run.