Some good info, let me add a couple of more wrinkles.
First, an inline UDF has a nickname, a parameterized view. It's way to set up a query, with parameters, to retrieve data in a very specified way, functioning like it was a table (or view). This can be really useful. That's why they exist and can be used instead of stored procedures (which don't act like tables) in some situations.
The weakness to using views is that they will be treated as tables instead of what they are, queries. By this I mean, that people will start to join one view to another instead of creating a new one when a new data requirement entails getting a bit of data from two different views. In this scenario, a query against 20 tables and another query against 20 tables has now been turned into a query against 40 tables. The optimizer starts to have problems. You'll also see people start to nest views, one within another, within another, while joining them to each other too of course. All because they look like tables. The problem is, they are not tables. Treating them as such can lead to very serious performance issues, not to mention maintenance headaches.
So, yes, views for reporting, generally a good thing. However, discipline in the use of the views is a must, which means educating your users on problematic approaches. For good or for ill, T-SQL (and most other SQL flavors) does not lend itself to code reuse like a proper programming language. So people see views as a way to simply reuse code. "I have my twenty table join. No need to ever write that again. I'll just reference it like it's an object." The optimizer starts to break down as the complexity of queries increases radically through this approach.