The answer to the title of your post is yes, of course.
The answer to 'when' is very subjective, and each developer ultimately forms his/her own criteria.
I typed an answer to this last night, but when I reviewed it I decided 'well this is all just subjective opinionated hooplah' and I deleted it.
Personally, I favor databases because I've been using them for so long. Therefore, the number of records doesn't have to get very big (50 or less) before I turn to that technology. If any sorting or filtering at all needs to be done, it's easier and faster for me to do it via SQL. So I would definitely put products into a database, although I might be tempted to try the articles using XML just to broaden my horizon, so to speak.
I don't have a lot of experience with XML; I've fiddled around with it on and off, and actually that's why I started looking at this particular forum - to learn how I can better use the technology. It appears to me that XML shines its brightest when transferring data between applications and platforms. It also shines brightly when a high degree of formatting has to be applied to the data.
I don't think you can ever beat a well designed database (both engine and data structure) on speed. XML gets to be a little clumsy in terms of storage because it is necessarily so verbose (you don't have to keep writing out 'book', 'book', 'book', 'author', 'author', 'author' in a database table).
Ease of edit/multiple supporting applications is a good point. If your content is coming from several collaboraters via CDs or email, XML would be an excellent medium to use to get ahold of the documents. On the other hand, if I were the sole content writer or my collaborators submitted via internet, I can put together an edit/update page in under 10 minutes (maybe under 5 if I don't get hung up on choosing a background color), so that would be one of my criteria. Another would be the size of the contributions; if I'm doing a site for book writers and the whole book is coming in, it makes more sense (to me) to store it as a file. However, I'd be tempted to store its filename in a table..
"Easier to move a site" is debatable (less direct interaction on your part, perhaps). Database utilities such as phpMyAdmin make backup/restore tasks pretty easy. Hosts which limit the number of databases you can have shouldn't be a major deciding factor - I haven't seen one yet which limits the number of tables you can have. While it may not be ideal, there's no reason you can't combine your CMS, bulletin board, and help desk into one database. I have seen hosts which limit the database's size, but personally I'd choose a different host <grin>.
The number of technologies available to us is just staggering, and it seems to be accelerating if anything. When it comes down to it, a well-rounded web developer needs to be intimate with a few, keep several more nearby, and keep abreast of what may need to be learned should the occasion arise. Which ones to use and when can always be argued, but really what it comes down to is "how's it look in the browser" - hard drives keep getting bigger and processors keep getting faster - sounds like a hardware problem <evil grin>...
Oh crud, looks like this is still subjective opinionated hooplah. Oh well.