...
The RDF specification says that identifiers need not be protocol-based and that it is perfectly possible to use any URI as an identifier (e. g. a URN)are compared character bv character (as specified in RFC 3986). This means that for a generic RDF handler, http://example.org/foo and https://example.org/foo are different resources since a URI comparator would say that the fifth character in the string differs.
Linked Data, however, is about the web so we need web-actionable identifiers. Deploying something like a resolver in between breaks the web approach: you have to educate users to use the resolver instead (which btw. has other disadvantages - bad experience with resolvers with DOI because the resolvers behave so differently. BnF experience: It's not sufficient to set an ARK on everything)
...
Does it make sense to change them to https as long as rdf, owl, skos, xsl ... don't change? Policy of these is to wait and hope that HSTS and UIR will still become good.
Another point is that the semantics of most of those vocabularies are hard-coded in the relevant tools (such as the OWL-API or Jena) so the identifiers are not dereferenced before they are acted on, e. g. for building class hierarchies using rdfs:subClassOf. That means that it would not really matter if the rdf namespace is identified by http://www.w3.org/1999/02/22-rdf-syntax-ns# or https://www.w3.org/1999/02/22-rdf-syntax-ns# since the semantics are known and the namespace identifiers are not dereferenced anyway. Terms, classes and properties from other vocabularies building on RDF, RDFS and OWL need to be dereferenced in order for applications to act on the properly, so here it does matter if the identifiers use http or https.
DCMI has had only one request for https so far and therefore currently doesn't see urgent need for action.
...