What I found that was more interesting to me (and not mentioned in this example), was that the output of the PRINT statement was changed. Here is my example:

Before RAISERROR:

15:30:02: Checking to see if data for 11/12/2013 has already been imported into the COPS_VPS_ASSOCIATION_TABLE... [SQLSTATE 01000]

After RAISERROR:

Msg 0, Sev 16, State 1, Line 60 : 16:00:02: Checking to see if data for 11/19/2013 has already been imported into the COPS_VPS_ASSOCIATION_TABLE... [SQLSTATE 01000]

The difference between the times and dates are because the second example was run one week + one half-hour later than the first example.

What I found interesting was that the presence of the RAISERROR prefixed my PRINT statements with RAISERROR-type data, i.e., Msg, Sev, State, Line. Furthermore, if the RAISERROR is not invoked, these PRINT statements print without this prefixed information. (SQL Server 2005, if that makes a difference.) I am intrigued by the fact that RAISERROR actually changed PRINT output that had already been spooled. My results also corresponded with this post. The following was the first output:

Msg 50000, Sev 16, State 5, Line 534 : The file for date '11/19/2013' is not ready. [SQLSTATE 42000]