So, I propose "id" keyword is removed from the next draft of json schema. Caveat: I have not implemented many schemas, so maybe I am missing some areas where it is extremely beneficial.

My objections:
Inline dereferencing:

• inline dererferencing is optional. It does not do anyone favors to have schemas that are not portable between implementations
• it is not trivial to scan a json schema and identify which "id" keys are actually keywords, for example:

{
    "x": {
        "id": "it is impossible to know if this is an id keyword or not"
    }
}

{
    "dependencies": {
        "id": "this is not an id keyword"
    }
}

Canonical dereferencing:

• due to the id keyword, it is possible to have $refs that are in a different scope, depending on how they are referenced. consider:

{
    "id": "base",
    "items": {
        "id": "anitem",
        "anyOf": [{"$ref": "#/x"}]
    },
    "properties": {
        "a": {"$ref": "#/items/anyOf/0"}
    },
    "x": {"type": "integer"}
}

the $ref within items has a different scope depending on if we are evaluating it from the items keyword (anitem#/x) or the properties keyword (base#/x). JSON reference does not have this problem, as the scope is always the uri of the document.

Maybe I just need to see some examples where id is highly beneficial, but it seems to me that you might want to use the id property, you could just as easily $ref the external schema. Simple inline referencing to fragment ids might be helpful in some situations, but scanning an arbitrary json object to identify them is not. And given the definitions keyword, it is much more helpful to use json pointer references to subschemas stored within that keyword. I just do not see the the benefit of id outweighing the difficulty if implementing it, especially given support may not be consistent throughout implementations.