Yes they matter, but not as much as they used to.
There's a lot of historical doco around that describes these things. How apposite that doco is depends from what operating system you have and how you administer your system.
For example: As M. Dickey says, if you still run the dump command, then the information in the freq column very much does matter, as it tells dump what to do. Conversely, if you are in the same boat as the answerer at https://superuser.com/a/247527/38062 , then the information in the dump column is probably not used by anything in your system.
The way that operating systems work in this area has changed significantly, and the relevance of these columns has changed.
Historically, one ran fsck in a boot-time script, with options that told it to read /etc/fstab and process all entries in pass-number order. And there's copious doco instructing you to pick specific values for pass numbers in the passno column, as you are alluding to in the question.
That doco is out of date. The world has changed.
systemd operating systems
On systemd operating systems, fsck doesn't have that responsibility any more.
The native configuration format for systemd is the unit, which can be amongst other things a service unit or a mount unit. systemd's service management proper operates solely in terms of those. Your /etc/fstab database is converted into mount and service units by a program named systemd-fstab-generator. This program is a generator, a type of ancillary utility whose job is to create unit files on the fly. It generates .mount units that mount the volumes and .service units that run systemd-fsck (which chains to fsck after setting up a client-server connection to a server that displays progress information) against individual volumes. /etc/fstab is effectively a source file and it is not the native control/configuration system.
The operation of systemd-fstab-generator completely ignores the freq column of /etc/fstab. And it only cares whether the passno column is zero or non-zero. If the latter, it generates references that cause the invocation of a systemd-fsck@device.service service to run fsck. If the former, it does not. So there's no difference if you choose 2, 1, or indeed 17035.
nosh
The nosh toolset also converts /etc/fstab to native form, which in the nosh case is a suite of service bundles. Its program for doing this is convert-fstab-services. This can be run explicitly, or one can make use of the auto-conversion system in /etc/system-control/convert/ to update service bundles whenever /etc/fstab changes.
Again, the freq column is ignored. (Don't be confused by the dump@device service bundles that it creates. That's to do with BSD crash dumping, not to do with filesystem backup via the dump command.) And again the only thing that matters about the passno column is that it is greater than zero, which is what causes a fsck@directory service bundle to be created and joined up to the mount@directory service bundle.
differences with noauto and fsck
The upshot of both the nosh and the systemd way of doing things is that instead of a single fsck being run in a mode that scans /etc/fstab and decides what to do, at one single point in the system bootstrap (or two, as in the case of the BSD rc.d system which tries to distinguish "background" from "foreground" volumes), running fsck is triggered by starting the individual "mount" services.
The filesystems that aren't mounted at bootstrap (because they are marked noauto) thus do not have their fscks run at bootstrap.
bootstrap fsck that does nothing anyway
Whilst passno matters inasmuch as it controls the generation of nosh service bundles or system service units that (indirectly) run fsck against individual volumes; sometimes that fsck is effectively a no-operation. Some filesystem formats simply don't have fsck tools that can operate in the "unattended preen" mode than one needs for these bootstrap-time/mount-time fsck invocations.
This is the case for at least:
For such filesystem types, the practical effect of passno is thus nil. Set it to zero, no fsck service will run. Set it to non-zero, the fsck service that runs invokes a program that does nothing.
Further reading
