Fascinating that FIPS not only permitted but basically encouraged them to roll their own crypto instead of using a standard, well-analyzed system. (They're being cautious about their approach but it's still more work to design something that's as safe as a known approach than to just use the known approach.)
I suspect that's the exact opposite of the intention behind FIPS....
FIPS is about the "correctness" of a particular set of functions (behaviors).
You are correct that part of FIPS is encouraging folks to use previous validated crypto modules instead of going from zero.
However you are not forced to do so - if you write your own crypto and pay to have it FIPS validated, more power to you - that's great. It is more competition.
FIPS is a double-edged sword in my experience. On one hand it does set a standard to keep total snake oil crypto out of government. On the other hand it often has the side effect of mandating worse and older crypto and slowing update cycles when there's a bug. When SSL bugs are discovered vulnerable SSL libraries tend to sit around for a lot longer on FIPS-controlled hosts because they have to wait for a FIPS-validated update.
My point was that you are not actively blocked or "discouraged" from making your own crypto implementation and submitting it for FIPS validation.
Of course, that will be more expensive and time consuming than simply reusing a previously validated crypto module. So, you could perhaps call that "encouragement".... but the idea of FIPS is to provide some level of assurance to the consumer of said solutions.
But there are cases where you desire to control your own crypto.
I suspect that's the exact opposite of the intention behind FIPS....