This is a stale question with a lot of answers but none had the answer I would have expected to be listed.
The short answer is:
- Use ASP.NET Web Forms if you're using or want to use a GUI-centric, RAD (Rapid Application Development), drag-and-drop approach to prototyping something very quickly, i.e. push-button / data grid behavior wired up within 15 minutes, and the solution is not intended to be something supported by developers. Or, Use ASP.NET Web Forms if you have a background in GUI or Windows Forms development and you desire to transfer your knowledge to the Web.
But to look at this properly, you have to understand the history of each.
ASP.NET Web Forms was Microsoft's answer to those who had been building dynamic web applications using Visual Basic 6 ActiveX controls, VB6 DLLs on the server, and ASP Classic. At the time, web development using these Microsoft tools was a real mess. Along with the entirety of the .NET Framework which was the output of Microsoft essentially going back to the drawing board on how to do productive business programming on the Windows stack, ASP.NET Web Forms was, in its day, amazing and beautiful. The whole approach was to give developers the best of both worlds of something very similar to Windows application development, but with the power of internet services. The idea was that, just as with a VB6/WinForms "Form" (a window) likewise a web page is a form (just like a window, see), and on that form you could drag-and-drop labels, textboxes, data grids, buttons, and other things that VB/WinForms GUI developers were accustomed to. To make a button do something, after dragging-and-dropping it you just double-click it in the designer and boom you're in the code editor, telling the form what to do when that "click" event happens. This was exactly how Windows GUI developers created software using GUI tooling of VB6 and competing tools, except now the code is executing on the server! Wow!
This was 2002 technology. Amazing and beautiful in its time as an answer to internet-enabled GUI solutions for RAD development, it brought a sense of power to a messy world of software developers that had business objectives that they needed to accomplish.
Unfortunately, this programming model emphasizes so much the metaphor of Windows GUI programming that it carries with it the burden of its necessary implementation details, all the encumbering baggage necessary to accommodate the event life cycles and the tucking away the ugly details of the simple HTML and script that these drag-and-drop components and controls would output. And at the end of the day, developers supporting real applications inevitably had to dig deep into these components or write their own, and consequently they would fight battles with this infrastructure, battles which would leave behind piles upon piles of cruft, pulled hair, and tears.