Here, briefly, are the basic options in ASP.NET. (only looking at inline versus server controls and code-behind)

I never minded the inline for the output of simple values that are only for viewing. e.g. label controls and viewstate are overkill. It makes easy stuff quite easy to read what the layout is with

h1%= _movie.Title %/h1
h3%= _movie.Director %/h3
span class=description%= _movie.Spoiler %/span

and alternative can be, when databound (asp.net)

h1%# Eval(Title); %/h1
h3%# Eval(Director); %/h3
span class=description%# Eval(Spoiler); %/span

or another alternative is to use server controls when you need more control and keep the markup readable.

h1asp:Label id=lblTitle runat=server //h1
h3asp:Label id=lblDirector runat=server //h3
asp:Label id=lblSpoiler runat=server CssClass=description /

in the 'code behind' file, at some point in the page life-cycle, you'd write....

lblTitle.Text = movie.Title;
lblDirector.Text = movie.Director;
if( string.IsNullOrEmpty(movie.Spoiler) )
{ lblSpoiler.CssClass=missing; lblSpoiler.Text = Resources(MissingSpoilerText); }
else
{ lblSpoiler.Text = movie.Spoiler; }

The reason for the inline styles is allowing for non-coders to change the markup without knowing the code. Obviously this can go too far when there's too much tweaking that needs to be done, but the idea is flexibility. Personally I don't dig Eval, because it's always better to catch errors at compile time, but sometimes easy works just fine. Not every page will get your undivided attention, and it does have the utility of showing what is being used.

The other benefit of inline styles in ASP.NET is (usually) you can alter the output on a live system. If you do everything code-behind then you have to recompile and redeploy. [I say 'usually' because in Web Deployment Projects you can specify that pages are not updatable at runtime]

The problem is that real websites, with real logic, get messy quickly no matter where the logic goes. But when things get messy, it's easier to refactor in code than it is to refactor in html.

%# (Eval(Prop) != null ? (Eval(Prop)) : Resources(PropNotFound); %

One thing in ASP.NET that I still find a bit persnickety is single and double quotes inside inline tags, and obviously this following is quite hard to read. I can't remember examples offhand, but there are still times inlining fails inside of some tags, but not others.

a href='%# Eval(Url) %' title='%# Eval(Title) %'%# Eval(Name) %/a -- watch ' versus !

At least MS, to their benefit, does allow flexibility. You don't always have to do it the same way, which is very handy. You can embed the name of events in the aspx file, but you don't have to (you can attach the delegate at runtime). You can just make a normal tag runat=server and then it becomes a member of the page. It can be a source of errors and frustration (knowing exactly where something is done) but that's an issue of DRY and following good coding practices.

Sometimes I curst that it's harder to write some forms of javascript because all the control names are mangled (based on the container they live in), but I get over it.

I don't think that flex and/or silverlight fix the problem of effectively marrying code to html, because they don't output html. It's not an apples to apples comparison, and not relevant.

The problem, you see, is html! I don't need another syntax that will, if it's to be as powerful (or broken) as html, will end up being almost, but not quite html.

It's very hard to create html that uses javascript (ie ajax) and proper css that really does work cross browsers for a decent sized web application while keeping everything easy to maintain / change and standards compliant and localized/globalized.