One of OWASP recomendations is to set the header X-Frame-Options to allow our pages to be loaded in Iframes only by sameorigin.
One reason is because of phishing attacks, ok I understand. But if I were an attacker and the target was configured to set X-Frame-Options to sameorigin, I could just copy the target page layout (html, css, js etc) and insert in my site.
What another reason we have to configure this header?
Phishing isn't actually the main reason, although the scenario you describe doesn't work if you're trying to trick the user into thinking they're signed into a site and don't know what the site looks like for that user. Phishing isn't just used to steal credentials; it can also be used to trick a user into taking some action within their authenticated account that benefits the attacker (such as authorizing the attacker's app to access the victim's account).
As Jeroen mentioned, the major risk is clickjacking / UI Redressing (another term for the same thing) attacks, where an already-authenticated webapp is loaded in an iframe on a malicious site, and the malicious site draws on top of the iframe to trick you into clicking somewhere that takes an action on the signed-in site that you didn't intend.
Imagine something like Amazon's one-click purchase. Somebody wants to get a bunch of people to each buy a $5000 "musical album" of car traffic noise. Obviously, nobody is going to do this by choice, so the "seller" puts a website that loads their purchase page in an iframe, and draws what looks like a free online game over it. The "Start game" button is drawn over the same place as the "Buy with one click" button, but the "start game" button actually just a spot on the page where part of the "buy" button is visible (with the text overlaid with "Click there to start"). All the rest of the Amazon shopping page is invisible. Somebody (who is signed into their Amazon account) who tries to start the game will instead send the attacker a bunch of money for something worthless.
There are sometimes also other attacks. For example, older versions of IE would render an entire page using the same rendering engine version, including content in an iframe; you could abuse this to attack pages that are vulnerable to very old attacks but were normally loaded by safe versions by creating a page that triggers the very old behavior and putting the now-vulnerable page in it as an iframe. There are probably other attacks like that, where the top-level page can influence the behavior of a framed page (or at least learn something about it), even though that's not supposed to be possible now. The main concerns are clickjacking and sometimes phishing, though.
