FPGA Timing Constraints
As some of the commenters observed, timing analysis can be a very complex topic.  In this answer, I will try to hit some of the important and practical points.

Q: Why is it important to constrain timing on your design?
A: So that internal (hard) timing constraints are met.

OK, so why is it important to meet internal timing?  This fundamentally boils down to the behavior of flip-flops (FFs) in your FPGA.  The timing of data relative to clock at each flip flop must meet certain requirements or the flip flop next state is indeterminate.  Think of the case where clock and data both change at the same instant at the input of the FF.  (what is the correct output value in this case)?  This is the gist of most timing issues.  So, the idea is to have the data stable for some period before (setup) and after (hold) the clock edge used to capture the data.  The tricky part here is that an FPGA is quite flexible on how things are connected inside, and all of the interconnect and logic has measurable, but design and placement dependent, delays associated with it.
The good news here is that modern FPGA (and CPLD) tools make it easy to ensure your circuit will work, if you define some timing constraints.  The tools perform the heavy lifting of calculating all the path delays and changing internal placement and routing to meet your constraints (if possible).
The simplest, and most important (IMHO) constraint is to define the maximum frequency of each of your clocks.  The FPGA tools will make sure that all internal setup and hold times are met between all of the FFs using that clock.  It is a good idea to also constrain your inputs and outputs relative the their related clocks.
The following is not really good advice, but rather a practical observation:  At low frequencies, it may be possible to not constrain at all.  Especially if the protocol (like SPI) has attributes that naturally provide margin.  The tools can identify clocks, and can tell you the max frequency possible for a given clock.  You can also determine as-built setup, hold, clock to out parameters.  In the absence of constraints, the tools will take a balanced approach to area / performance during compilation.
As an example here:  if the SPI_SCLK is 1MHz (or below), you probably don't need to worry about timing being an issue.  There is about 500ns of setup and 500ns for hold (data to clock) due to the SPI protocol.  That is a lot of margin in a modern programmable.
If you fail to meet (FPGA internal) timing, the circuit behavior can be totally unpredictable.  You really want to avoid this.