A semantic model is not a technology. The same meaning can ship as a graph, an API, a data product or a contract — decide what it means before deciding what to buy.
"We need a semantic layer" is routinely answered with a procurement decision, and that is the wrong order. A semantic model is a statement about what the business means: the concepts, their relationships, the rules that hold. How it reaches consumers is a separate question with several valid answers — a knowledge graph, semantic APIs, data products, data contracts, virtualisation, a BI semantic model, metadata services.
Once separated, the choice becomes analysable instead of ideological. Relationships and reasoning matter most? A graph earns its cost. Need to expose Customer and Order as business concepts rather than raw system structures? Semantic APIs. Want trustworthy, reusable data with ownership attached? A data product. Need business definitions bolted onto technical schemas? Contracts. Different semantic responsibilities can use different mechanisms in the same organisation, and usually should.
The failure mode of the reversed order is familiar and expensive: the technology arrives first, and the semantic model is then bent to fit what the tool models well. You end up with an accurate description of the product's data model rather than of the business, and nobody notices because the artefact looks like semantics either way.
The corollary is that one business concept can be sourced from many systems and delivered through many implementations — Customer arriving from CRM, ERP, the warehouse and support, then served as an API, a data product, a graph and a BI view. That is only coherent if the concept was defined once, independently of any of them. Decide the meaning; then choose the mechanism.