If the number changes nothing on screen, why does anyone care about it?

Because print software has to decide how large to place the image, and the resolution field is where it looks. Without a stated density there is no mapping from a pixel grid to a sheet of paper at all — the grid is dimensionless until something says how tightly to lay it down.

Is 72 dpi a real property of a web image?

No, it is a default that stuck. Early Macintosh screens were near 72 pixels per inch, and software has written that figure into files ever since for want of anything better. A file marked 72 dpi is almost always a file whose density was never considered, which is different from a file that was measured at 72.

Can a printer be told to ignore the field?

In most layout software, yes: place the image and set the frame size explicitly, and the stored density becomes irrelevant. Automated submission systems are the exception, and they are where this matters, because they read the field and have no operator to override it.

DPI is metadata, not detail

A file has pixels. DPI is a separate number saying how many of them are meant to occupy an inch of paper. Everything confusing about image sizing comes from those two being treated as one.

Two facts, stored in two places

Open any photograph in a text editor and you will find, near the front, a short run of bytes that has nothing to do with the picture. In a JPEG it is a density unit and an X and Y pair inside the JFIF segment, repeated as a rational number in the Exif block. In a PNG it is nine bytes in a chunk called pHYs. Delete those bytes and the image still decodes, still displays, and still occupies exactly the same grid.

What is lost is the file’s opinion about paper. A grid of 1200 by 800 pixels has no physical size of its own; it acquires one only when something states a density. At 300 pixels to the inch that grid is a 4 by 2.67 inch print. At 72 it is 16.67 by 11.11 inches of the same pixels spread much further apart. The picture did not change between those two sentences. Only the instruction did.

This is the whole content of the claim that DPI is metadata. It is a label attached to the data, in the same way that a caption is, and altering a label is not an edit to what it labels.

What actually happens in each of the two modes

A tool offering to “change the DPI” is offering one of two very different operations, and the difference is invisible in the interface of most of them.

Setting a 1200 x 800 file from 72 dpi to 300 dpi
	Print size only	Resample
Pixel grid afterwards	1200 x 800	5000 x 3333
Print size afterwards	10.16 x 6.77 cm	42.33 x 28.22 cm
Image data	copied byte for byte	recomputed by a kernel
Detail recorded	unchanged	unchanged
Detail present per inch	higher	the same

The last two rows are the ones worth sitting with. Print-size-only mode raises the detail per inch of paper, because the same recorded detail is being crammed into a smaller sheet. Resample mode holds the sheet the same size and manufactures pixels to fill it, so the detail per inch of paper is exactly what it was — you have simply stored more numbers describing it.

Neither operation adds information to the file. Only one of them adds bytes.

Reading the panel while you decide

The resolution field on the right-hand rail carries a line underneath it saying which quantity is being held. If it reads that the print size is held, editing the resolution will move the pixel count; if it reads that the pixels are held, editing the resolution will move the print size. Watching which of the other two figures moves is a faster way to understand the identity than any explanation of it.

The rule of thumb, stated plainly

If something has told you a number and the picture is already good enough, you want print-size-only mode. If something has told you a physical size and a density together, do the division first: multiply the inches by the density and compare the result against the pixel count you have. If your file already meets it, you still want print-size-only mode.

Resampling is the answer only when the pixel count itself is wrong for the job, and even then it is worth knowing which direction you are going. Downward, a kernel is discarding information carefully and the result can be excellent. Upward, it is filling in between samples, and the ceiling on the result was set by whatever recorded the original.

Questions that follow from this

If the number changes nothing on screen, why does anyone care about it?: Because print software has to decide how large to place the image, and the resolution field is where it looks. Without a stated density there is no mapping from a pixel grid to a sheet of paper at all — the grid is dimensionless until something says how tightly to lay it down.
Is 72 dpi a real property of a web image?: No, it is a default that stuck. Early Macintosh screens were near 72 pixels per inch, and software has written that figure into files ever since for want of anything better. A file marked 72 dpi is almost always a file whose density was never considered, which is different from a file that was measured at 72.
Can a printer be told to ignore the field?: In most layout software, yes: place the image and set the frame size explicitly, and the stored density becomes irrelevant. Automated submission systems are the exception, and they are where this matters, because they read the field and have no operator to override it.