Here are my opinions, but they're just opinions. There are lots of different approaches that can work.
1) Your databases should serve the needs of your business systems, not your reporting system. Your reporting system (QlikView) should then do the data manipulation and formatting necessary for its reporting.
2) Extract to QlikView directly. Again, the databases serve the business system, not the reporting system, and QlikView is perfectly capable of doing the data manipulations required to translate for its own needs.
3) I store fairly but not completely raw data in the QVDs. Let's take a hypothetical example. In our business system, we store both customers and suppliers. We might have three different tables. One is a "business entity" table that stores information that all of our business entities need, with a cryptic field like BEID as our ID. Then we might have a separate table for customer-specific information, and a third table for supplier-specific information, with IDs of CUID and SUID. A lot of the fields on these tables might be codes to be looked up on yet another database. Like you might have a CRST (credit status) field with a value of "03" that, when looked up on the other table, really means "require payment up front".
I would NOT try to replicate this structure when building QVDs. In a sense, I would shift to a more object-oriented approach, in this case, having a customer object and a supplier object. So I would create a Customer.qvd and a Supplier.qvd. Rather than the cryptic field names, I would use "Customer" as the customer ID, and "Supplier" as the supplier ID, as well as naming all of the other important fields something more human-readable. I would only include fields that people wanted to see on reports, not all fields in the database. If someone wanted to see the information, I would go ahead and add field "require payment up front?" with Y/N values to the Customer QVD, rather than storing a separate table to look up this one piece of data. Basically, QlikView's compression makes this sort of denormalization a non-issue. I'd also put date fields in QlikView's date format, and that kind of thing.
I wouldn't personally go any farther than that, and we don't in our shop. I'm a fan of having the QVDs be very basic objects with little manipulation. I feel that gives them the greatest chance of being useful to the greatest number of reporting applications. But if you find yourself doing the same manipulations over and over in the applications, by all means do them when creating the QVD rather than giving yourself a maintenance nightmare of having very similar script in a number of different applications.
In regards to optimized loads, I've recently started doing all optimized loads with my most restrictive possible exists(), and then doing additional manipulation in memory. For instance, then inner joining to an inline load of allowed values for some field. That's worked well so far, but I can't say for sure that it will continue working well. Most of my existing applications use unoptimized loads and are quite slow to load. Up to now, my concern has been much more for execution speed while someone is waiting for a chart than load speed, so I'm not really a load speed expert.
