To add to the answer provided by j:

1. CORS Issues
2. SSL/non-SSL issues.
3. ad blocker extensions - they can block certain iframes as some of them are for ads or tracking.
4. Page load time is increased (not good) - especially if the iframes are visible - not just 0x0 pixels.

The biggest problem is the one that is half of why IFRAME was deprecated in 4 strict -- accessibility woes. Hence why the tag only really came back in HTML 5 due to its use in embedding advertisements, videos, and other non-textual off-site content where the potential protection mechanisms may be of benefit.

Screen readers, braille readers, and other alternative non-visual browsing methods generally don't see the content of IFRAME and/or have great difficulty navigating to and out of them. As it is basically an accessibility violation this also means search engines can get confused as to what on the page to even link to. Google is a lot better at this than it used to be, but remember that whilst in the west crazy Goog may be the tops, in the rest of the world Baidu and Yandex are king.

The other half of why it was deprecated being it is redundant to OBJECT, but since IE dragged their heels on making an OBJECT implementation that worked properly for... well... anything, and the JavaScript side of things is too "restricted" by how OBJECT works, and OBJECT is often more code... You can see how OBJECT adoption for anything but flash player was slow.

Did you know originally the next version of HTML after 4 was supposed to drop IMG in favor of OBJECT as well? But no, along comes the WhatWG and they not only leave IMG in, they add VIDEO, AUDIO, and CANVAS creating all new pointless redundancies, whilst letting the old EMBED redundancy back in! One step forward; two steps back.

Generally speaking you should avoid using IFRAME (or framesets) for anything content or navigation related, restricting it to things like youtube video player embeds and off-site advertisements.

Pretty much anything you would think of doing with an iFrame is often faster/simpler/cleaner to just paste together server side if you're practicing separation of presentation from content and leveraging your semantics... where the average page should be 2k + 128 bytes per anchor + 256 bytes per media element + content text size * 1.5... where a page with 6k of plaintext really has little reason to be more than 16k of code maximum.

Hence why when I see pages with 6k of plaintext and a half dozen content images blowing 60 to 100k of markup on it, I automatically assume complete developer -- here are those words again -- ignorance or incompetence. See 99.99%+ of what people slop out with bootstrap and have the unmitigated gall to call a website! I call it "bootcrap" for a reason, as people really need to start scraping it off with a stick.

If you move as much of the presentation as you can out of the markup, and generate any scripting only elements and behaviors from the external files avoiding STYLE (the tag or the attribute) and not derping static scripts into the markup, using monolithic files for both, the style and scripting can be cached! This means your smaller leaner markup of subpages using the same styles can load faster and you can even pre-cache the appearance of different page layouts.

... meaning that the so called speed, simplicity, and bandwidth improvements that frames -- much like AJAXing in content and methods like CSR -- might provide are revealed for the tissue of lies that they are.

Thusly I'd stack a good PHP include(); up against building with frames any day when putting together content coming off the same server.