You index JSON columns in SQL Server by creating an index on a computed column. I am very open to the strict argument that this is a workaround if you'd like to make that more verbosely. Nevertheless it is very effective and adds minimal IO overhead and is dispatched with one extra line of code (more if you prefer newline-heavy formatting). From a practical perspective this has never been a sticking point for any of numerous clients I have seen using the features, and the performance is as good as any other btree index.

You are correct that there is no formal SQL type in SQL Server for JSON. And I am sorry for implying otherwise. Type safety requires a constraint on the column intended to hold JSON.

There is no equivalent to Postgres's GIN indices which would allow indexing on an array in the JSON column. Such a requirement would need a normalized table holding the array's values in SQL Server. Whether this is a limitation or a lack of support for JSON, full stop, seems to me a matter open to debate.

I have seen many successful projects (and participated in quite a few of those) that utilize JSON in SQL Server databases. I will amend my former statement, though, because it obviously lacked nuance: SQL Server's JSON functionality has covered all use cases that I have had and personally seen, but my experience is obviously much lesser than some others', so you can take this experience with as much salt as you like (: