I think that the best thing about ITVF versus direct access to views is that you can enforce some parameters to be provided.  So even if views (indexed or not) do exist underneath, with an ITVF, you can require, for instance, a parameter to filter on date range or customer or whatever.

If you limit access to only the ITVF and not the tables and views underneath, then users/developers/whatever will always have to provide those parameters - this can give a number of advantages:

Limit accidental data leakage - no more forgotten WHERE clauses or weird inadvertant cross-joins when a table is not limited the way it should have been either in the join or in a where clause

Limit long-running queries - no more selecting all 5 billion rows from a datawarehouse fact and associated dimensions when you should only be selecting a particular financial period or a particular date or similar limitiation

Defensive coding and security in-depth - limiting scope of data accessible in a particular interface accessible by a particular user in a single call is yet one more way to limit potential misuse, whether due to bugs or vulnerabilities - coding defensively anticipates not how the code will be misused, but is general approach to limit the places where problems can happen by reducing surface area in general

Focus thinking on actual use patterns - when parameters are always needed to be provided, this exposes a lot more of how the system works explicitly through the interface of the function instead of arbitrary column usage.

Basically, codifying the expected access path and providing just that interface does the same thing you would expect it to do based on the general principle of defining interfaces in software - it controls and conforms access and gives you control of the surface area.