The performance overhead of master pages is absolutely minimal. Pulling the performance argument on master pages shows complete lack of understanding how ASP.NET works.
Indeed, ASP.NET executes fully compiled. And fully compiled means that the pages are actually compiled all the way to native machine code.
NERD ALERT: The following is rather technical and understanding it is not required to use Master Pages
What can be confusing is that there's actually several compilations and intermediate code levels on the way down to machine instructions:
ASP.NET parses the .aspx file and produces a (partial) class which is compiled combined with whatever codebeside is associated with the page (the .aspx.cs or .aspx.vb file). The result of this compilation is a class represented in IL code. IL is Intermediate Language, sometimes also called CIL or MSIL.
The IL code is then compiled into machine code. And finally the code executes. This compiled code is also kept in a secured cache which is managed by the .NET runtime. If a request comes in for the same .aspx file (need not be the same user), the .NET runtime simply fetches the code from the cache and thus bypasses the compilation steps. The cache has cache dependencies which ensure that if you touch any of the files the compiled code will be evicted from the cache. Upon next request for the page this will guarantee a new compilation.
As wwb said, an ASP.NET page is not merely script, like e.g. PHP or classic ASP. Rather, a page in ASP.NET is compiled into a class with initialization code which (once it is executed) builds the control tree of the page. Your code then manipulates this control tree (follows the Composite GoF design pattern), and finally the tree is traversed and each node is asked to "render" itself in a depth-first fashion.
The control tree is where ASP.NET gets its strength, especially its composability. If you are curious about it you can switch on tracing (Trace="true" in the @Page directive). This will document the exact control tree for the page as it looked at rendering time.
Back to the Master Pages. A master page is compiled as a separate unit (as is user controls). It is not compiled in with the content page. Curiously, a master page is actually more a control than it is a page - but that's for another day. All it need to is to hook into the initialization of the control tree.
The content page is the one handling the request. When a master page is in play the content page initializes its content regions, but delegates the initialization of the control tree to the master page. The master page then goes back to the content page to look up the content (sub trees) for the individual regions. The result is a control tree in which the controls of the master page and of the content page are neatly combined.
As you see, even though the master page is compiled into a separate unit, there is a protocol/contract which allows it to play efficiently with the content pages. Indeed it is so decoupled that if you edit a master page, only the master page will be recompiled. Although the content pages are going to run with a changed control tree, it doesn't affect their code at all.
As wwb said, the Master Page is incredibly versatile. You can even have code in the content pages which during the pre-init phase dynamically sets which master page they should be rendered with.
A master pages also has its own, dedicated controller. It can be used to implement e.g. login functionality and will then work on every content page. It will not interfere with the content page controller.
If content regions are too coarse for your particular requirement, you can expose properties and/or methods from the master page. These methods can be called by the content pages to manipulate the control tree or do other stuff. It can be that from some pages you want to "hint" the adrotator to rotate another set of ads.
Master Pages are one of the most compelling features of ASP.NET. Once you get to know them you will never look back. Promise.