Use JSON serialization to get around parameter limitations for future methods?

A few thoughts:

• If you are dealing with a collection the string resulting from JSON serialization could become prohibitively large. This could result in heap size limit issues during deserialization.
• The data in the sObject may be stale by the time the future method executes. Fields may have been changed on the Contact before the future method runs.
• You may be serializing and passing data that you otherwise don't care about. E.g. You probably wouldn't want to serialize a blob data field.

Weather any of these are an issue or not will entirely depend on your usage.

I've actually utilized this pattern to @futurize restful api callouts. In my case they objects were sObjects, but sobjects I wasn't worried about changing on me. As a design pattern, it works fairly well, even with moderately sized objects.

However, Daniel brings up the single most salient point, and one that needs to be re-iterated. If you choose to implement this pattern, you must start adding heap-stress-tests cases! I like to set my own heap "limits" and assert that Limits.getHeapSize() is below my own limit. This lets me isolate the heapsize used by json de/serialization of exemplar objects. That way I have some idea what my heapsize budget is for the rest of the @future call.