My observation is that WebForms is on the decline. There is a good reason for that. Having used WebForms extensively in the past, it's difficult to do something outside the box. In addition to the learning aspx controls and their proper usage, there is a lot of technical minutiae to learn about the page life cycle when going beyond basics. And in the end, you are writing in a proprietary XML-based language which translates itself (often poorly) to the HTML+JS which you actually have to support in target browsers. Often the control's rendering implementation leaks through to be your problem, and you have to make it work with JS/CSS hacks on the rendered output. Declarations are quite verbose and sometimes don't translate to quite what you envision they will in HTML. When you need to apply classes for styling, this means you also must become intimately familiar with how the control renders HTML. The stock controls use a lot of antiquated HTML standards like table-based rendering. Thus why several 3rd party control vendors exist for WebForms.
(Edit: I didn't even get into View/Control State here. I must have blocked it out. Here is an example article explaining view state and page lifecycle interactions (25 printed pages).)
MVC and later client-side frameworks like Angular like to expose you directly to the HTML/JS because that's what you actually need to know and have control over anyway. Note there exist 3rd party MVC control vendors which render some HTML/JS for you.
My past employers have used WebForms projects (some extensively). I have created several. I maintain several in production today of mine or others creation. I think anyone I know working on WebForms projects now considers them "legacy" and only touches them when required. New functionality gets migrated to something else. We have angular-based pages inside most of our WebForms projects where new functionality was needed.
Specifically of your co-worker. If WebForms is something that your team supports, then it runs counter to most agile practices to be specialized to only MVC. "Anybody on the team should be able to do any task." That's the ideal. I've been on teams where it was agreeable to all parties (except the Product Owner) to be specialized. However, that can become a blocker to getting the highest priority stories done if the specialized person's availability is low due to vacation or illness. If it's a team goal to have everyone cross-trained, then everyone should continue to cross-train as opportunities present themselves.
I'm sure someone could make a career doing only MVC in .NET. It's pretty easy to indicate your preference to employers on a resume and in interviews. However, I would not limit myself to that. MVC on .NET is a tech (and a lesser used one in the grand scheme), and techs come and go. I don't use WebForms or MVC for new web front ends and have not missed either of them. MVC sometimes sneaks in on the API side of things because it has gotten commingled with Web API on some project templates.
