I have heard countless reasons on why not to use HTML frames, from their lack of accessibility, the general lacking in UX, their being completely inefficient/unmaintainable, or them just being outdated.
This all brings me to two questions:
(1) Not inherently. iframes have many use cases that do not suffer from the problems of frames. They're useful any time you want to mix in a document from another security context, or without the scripting and styles that the parent page is using.
However, it is possible to ‘use an iframe like a frame’: to split the page up into separate iframe areas, with cross-frame-links making a navigational mess that doesn't play well with bookmarks, open-in-new-tab etc.
(2) I would not use frames for anything today. There was a limited use case for them keeping hold of large amounts of page content that you don't want to reload on each navigation. But these days we would just use XMLHttpRequest to update part of the page instead.
Even so, without care taken to make page-changing links accessible (using hash-history and having a static-link analogue for each hash-link, linked with real <a>s that response to middle-click et al), a page that updates/navigates itself using XMLHttpRequest will recreate many of the navigational problems of frames, with strongly negative usability, accessibility and SEO implications.
I find it a bit sad that many authors are creating flashy, swooshy, “modern” animated web sites that, by naïvely using jQuery's load() or similar on its own, exhibit all the worst behaviours of ancient, hated frames.
(1) No. There are legitimate uses for iframes, where there's no reason to use frames today with modern browsers.
(2) Never use frames; there's other better easier solutions available to produce the same effect.
Use iframes only when embedding the whole site is the most logical option. Although rare, there are occasions when this makes sense.
In short, there's a reason why the frame/frameset/noframe tags are taken out of HTML5, but the iframe will carry over.