The GeoJSON working group chose to omit links from the specification (outside of coordinate reference systems). In conclusion, GeoJSON 1.0 is not a hypermedia format. Without links there are no levers of application state to be seized, no hypertext constraint, and therefore no REST.
Consider, as an example of a hypermedia format, Atom and extensions in AtomPub: "alternate", "related", "self", and "edit" links are designed to satisfy REST's hypertext constraint and permit hypertext to be used as the engine of application state. Without links of the edit kind (especially), HTTP Geo-CRUD protocols using GeoJSON couple clients and servers together, an undesirable property in a system like the Web. This is not to say that coupling is going to kill your applications, just that the components don't have much freedom to evolve (think migrate or upgrade) separately.
Are there any good linking options for JSON? Subbu Allamaraju explores that question here and here and floats an object not unlike the only link example in GeoJSON. Both are inspired by atom:link and HTML's link.
Should GeoJSON become a hypermedia format? I don't know the answer to that, but I think it's more likely that GeoJSON geometry (and maybe feature) objects will find their way into other yet-to-emerge JSON-based media types.