Should we be making the effort to expose our custom modules' fields to Views,
Definitely. Your users will want this.
and then generate lists we want with the Views module?
This is of course optional, but has many advantages. One is ease for you as a developer. Yes, you know how to generate these lists manually. Still, it's coding time to generate them and then modify them when a changed UI is wanted. Assuming you've already taken to the time to expost your data to Views, the task now becomes easy. You build your views to spec, export them, copy the code, and put it into a hook_views_default_views() implementation. Want some change to the presentation? Change your view, then re-export. Key advantages as I see them are: 1. Reduced code that you need to maintain. A default view isn't really code you're stuck maintaining--it's something you can configure and reconfigure through a UI. 2. Flexibility for your users. Seldom will you be able to hard-code a data presentation that's exactly what all your users want or need. By providing a default view, you give your users your best guess, but leave them full control over customizing to their own needs. 3. Examples to work from. Depending on the complexity of your module and its data presentation, it may be difficult for some admins to figure out how to construct effective views of your data. This is especially true if you e.g. expose argument fields or have complex filtering possibilities. Besides accomplishing their direct aims, default views also provide useful tutorials for admins wishing to take advantage of your views implementations.