To be scrupulously fair, there are essentially two different ways to implement a Schmitt trigger.
One way involves feedback connected to the input pin. This inherently lowers the impedance of the input and that alone makes it less susceptible to noise, even before you consider the altered comparison threshold.
The other way, such as in a 74HC14, involves a very high impedance input, but the threshold the input is compared to is internally modified. Modifying the threshold also makes it less susceptible to noise, but the impedance is so high that it still might have some susceptibility, especially if it's, e.g. routed to a connector pin that might not be populated.
Your statement:
> The entire point of Schmitt triggers is to not switch back and forth constantly without a good reason.
is essentially true, and some Schmitt triggers, such as those on many CPLDs and FPGAs, work by repurposing pull-up/pull-down circuitry, but not all of them work that way.
Schmitt triggers, in the general case, are circuits that cope with slow rise/fall times and a bit of noise on the input pins, rather than circuits that properly cope with completely undriven inputs.
In fact, FPGA-style low-impedance Schmitt trigger inputs can wreak havoc on things like the I2C protocol, because you might be effectively altering the undriven impedance and voltage of the bus, so you might want to put a discrete Schmitt trigger inverter in front of the FPGA in some cases, or, if you have enough pins, perhaps use a differential input on the FPGA and a couple of resistors and a separate output pin to set the threshold.
