Documents which intend to be embedded cross-origin ought to positively opt-into that state. Documents which do not explicitly opt-in to being embedded in a particular context will be blocked unless all of their ancestors are same-origin (similar conceptually to the behavior of `X-Frame-Options: SAMEORIGIN`). This shifts both the burden and the risk to those sites which actually wish to be embeddable; developers who take no action will be safe by default. Embeddable documents can opt-into the embedding by sending either an appropriate X-Frame-Options header, or a Content-Security-Policy header that asserts a frame-ancestors directive.
Documents can embed anything they like via `<iframe>`, `<frame>`, `<embed>`, and `<object>`, thereby exposing those embedded resources to attacks ranging from the well-known risks of clickjacking to the less-understood side-channel risks of XSLeaks and Spectre. Developers can mitigate these risks by choosing to limit the ways in which particular resources can be embedded. The `X-Frame-Options` header and CSP's more-granular `frame-ancestors` directive both provide developers with a measure of defense, and are both fairly widely deployed. That said, as attackers continue to improve their ability to extract cross-origin information in unexpected ways, it becomes increasingly unfortunate that we place the burden of this defense on the victim. It's unfortunate both because it's one more thing for victims to ensure they get right, and because some scenarios make it quite difficult for victims to do the right thing (consider error conditions rejected by a reverse proxy; the application layer might never even have the opportunity to set up a defense).