Trust, reliability and visibility
In the support document for their early work on schema.org metadata, then known as rich snippets, Google said this about hidden metadata:
In general, Google won't display any content in rich snippets that is not visible to [a] human user.
https://support.google.com/webmasters/answer/1093493#hidden
One of the potential  advantages of the schema.org approach of marking up visible information as metadata over other ways of providing metadata is related to the trustworthyness and reliability of the data. Experience with early alternatives for providing metadata about web pages such as embedded <meta> tags in the header containing or linking to information intended for use by search applications suggested that such approaches yielded poor results. Sometimes the information provided was inaccurate due to deliberate attempts to mislead the search engines with data that suggested the web page was relevant to popular subjects; sometimes it was simply that the author of the content of a page had started with a template and hadnt changed the metadata in the header to match the content. The developer of one of the larger vocabularies to be incorporated into schema.org describes Googles (and other search engines) likely rationale for mistrusting hidden metadata this way5: 
1. invisible markup invites spammers that try to manipulate the search engine,
2. a link to human-readable content allows [the combination of] structured data and the textual content for information extraction heuristics, and
3. the data quality is likely higher for visible content (since humans will complain otherwise).
Martin Hepp, JSON-LD: Finally, Google Honors Invisible Data for SEO 
There are some disadvantages to providing data using schema.org that stem from the constraint of marking up the text that is displayed. There may be a valid clash between the data that you want to provide a search application and what you want to display to users of your website. For example you may want to provide a URL to identify a resource unambiguously but without presenting users with a distracting link. The schema.org help documentation suggests the use of <link> or <meta> tags to embed this information but not to display it (see note below), with the caveat
This technique should be used sparingly. Only use meta with content for information that cannot otherwise be marked up.
http://schema.org/docs/gs.html#advanced_missing
More subtly, putting metadata within the tree of elements that make up an HTML document places that information into a hierarchical structure which contrasts with the more flexible graphs that semantic web languages such as RDF allow. In the post quoted above, Martin Hepp describes this as violating the principle of separation of concerns  you have to align a given HTML tree structure with a given data structure, dictated by the schema.org ontology. Thus, as in the simple example provided above, all the information about the person who is a contributor to a creative work all sits within an HTML element that specifies that the information relates to the contributor property of that work. This becomes problematic when one wants to provide extensive detailed information about items that are used to give values for properties such as contributor, especially where the same information is repeated. Imagine four people have contributed to the resource and all four work for the same organisation: the nesting hierarchy means that all the information about the organisation has to be repeated for each person. Furthermore, imagine that some of these people have contributed to several resources described on the same page: the amount of redundant repetition of data multiplies. Provided an item (in this case the person who made the contribution or their affiliation) is uniquely identified a search application may aggregate information about that item from several sources, in which case there would be no need to repeat the information in the documentbut equally, they may not. There are mechanisms for jumping out of the nested hierarchy, for example the itemref property in microdata allows links to be made between items described in separate sections on a webpage6, however it is unclear how well this is supported within schema.org. As Martin Hepp points out in the blog post quoted above, the recent adoption by Google of a JSON-LD serialization of schema.org metadata that may be embedded within a webpage without being displayed is a step away from the insistence that the data marked-up with schema.org should be visible to humans. However the conditions under which Google will trust this metadata are not known.
