Why don't on board communications like I2C, SPI, etc. have error checking in general?

You have to assume certain things just work, even in a world with error checking. Why pick on IIC or SPI when there are usually many more digital signals on a board? You seem to be OK with assuming those will all be interpreted as intended.

A properly designed circuit on a properly designed board should be reliable. Think of a CMOS output driving a CMOS input across a board. Other than outright component failure (which is a whole different problem from occasional data corruption), think about what can actually go wrong. At the driving end, you've got a FET with some maximum guaranteed on resistance connecting a line to either Vdd or ground. What exactly to you imagine can cause that not have the right level at the receiving end?

Initially the state can be undetermined as whatever capacitance on the line is charged or discharged. Then there can be ringing in the short trace. However, we can calculate maximum worst case times for all this to settle and the line to be reliably across some threshold at the other end.

Once this time has been reached and we've waited for whatever the worst case propagation delay of the logic is, there is little to change the signal. You may be thinking noise from other parts of the board can couple onto the signal. Yes, that can happen, but we can also design for that. The amount of noise in another part of the board is generally known. If not, then it's coming from elsewhere and in proper design it would be clamped to be limited to some maximum dV/dt and other characteristics. These things can all be designed for.

External noise can in theory upset traces on a board, but the field strength would need to be unreasonably large for a properly designed board. High noise environments do exist, but are limited to known locations. A board may not work 10 meters from a 10 kW transmitter, but even that can be designed for.

So the answer is basically that digital signals on the same board, if designed properly, can be considered absolutely reliable for most ordinary uses. In special cases where the cost of failure is very high, like space and some military applications, other strategies are used. These usually include redundant subsystems. You still consider individual signals on a board reliable, but assume boards or subsystems as a whole may occasionally err. Note also that these systems cost much more, and such a cost burden would make most ordinary systems, like personal computers for example, useless by being too expensive.

That all said, there are cases where even in ordinary consumer electronics error detection and correction is employed. This is usually because the process itself has a certain error probability and because limits are being pushed. High speed main memory for computers often do include extra bits for error detection and/or correction. It's cheaper to get the performance and ultimate error rate by pushing limits and adding resources to error correction than to slow things down and use more silicon to make everything inherently more reliable.

Especially for protocols that are not designed to be used over cables, a properly designed board won't have errors, and a poorly designed board won't work well with or without error checking. For example, glitches on an I2C bus with multiple slaves can permanently lock up the bus(*) unless the master has a driver that can pull SDA high even when slaves are trying to pull it low. Guarding against that would make the protocol slower, but if the bus is sufficiently free of glitches that such possible behavior is not considered a risk, there wouldn't be much need for error-checking logic in general.

(*) If a slave thinks it sees a start condition in the middle of a data byte being read from another device, and interprets the data being read out as starting a command that should read out a string of zeroes, then it would be possible for each of the slave devices to acknowledge data bytes sent to the other in such a way that at any given time at least one of the slaves would be holding down the bus.

Why do you ask that only regarding error checking?

How can you be sure that the start condition is interpreted correctly? On wireline or wireless communications, the start of frame is a very complex combinations of bits, while on RS-232 it is a simple high to low change, and on I2C a simple protocol violation.

My point is that not only error checking is different, but all the elements of the protocol are much, much simpler for on-the-board protocols than their counterparts for wireline and wireless communications. And the reason is that the probability of error is several orders lower than for wired/wireless communications.