Hello David
Yes, you are correct, creating a specific static route for 5.5.5.5/32 over the primary link will prevent route flapping. However, if the primary path does have connectivity problems, the traffic to 5.5.5.5 will indeed hit a dead end as the specific static route is still pointing over the primary link, even though the SLA will reroute all the rest of the traffic over the secondary link.
There are a couple of solutions to this. The first is to use a destination for your IPSLA that isn’t mission critical. For example, if you want to be able to reach a server with an IP address of 5.5.5.5, use the IP address of another device on the same subnet, say, the default gateway of that server (i.e. 5.5.5.6, or some other address on the same subnet). This presupposes that you can get that information somehow, but you can probably find some auxiliary IP address that you can use for that purpose. So if you lose connectivity to, say, 5.5.5.6, your IP SLA will kick in, but you will still be able to reach 5.5.5.5 via the secondary link.
Another solution is to use Policy Based routing (PBR). PBR can be used to change the next hop IP address for traffic matching certain criteria, thus overruling your routing table. You can have your IP SLA test always go over the primary link, and if that fails have the IP SLA kick in. But all your other traffic, using PBR, will be able to reach the intended destination via the secondary link.
Concerning the difference between the reachability and state keywords for the track command, this Cisco command reference documentation clarifies this quite nicely. Essentially, the difference has to do with whether or not the response to the echo request comes before or after the set threshold. Take a look at the documentation and if you have any more questions, let us know!
I hope this has been helpful!
Laz