It was divested for a number of reasons. First, there was (and still is) the Python 2 to 3 transition. Supporting Python 3 added a lot of overhead while full Python 2 support was not available yet.
It also turns out that a lot of popular Python libraries have dependencies on C/C++ code, so there were attempts like IronClad to provide support for these, but it wasn't as easy as CPython. There were benefits like the CLR being able to handle some workloads better than CPython with its GIL, but there are expectations in some libraries that it's CPython running the code.
Startup performance also takes a hit due to jitting, so IronPython had to implement some tricks to make it run scripts fast on the first run. This is a pretty common case.
Then you add in compatibility and testing with frameworks like Django, and balancing that against further development of the core. Even if you support these frameworks, you may not be able to support some of the libraries and tools that these developers coming from the open source world use, so their experience can be soured and the project appears to be more of a science project. That said, IronPython can excel in niches, such as adding scriptability to your .NET app. But that's not going to take over the world.
These problems also applied to IronRuby. Both of them seemed to be joined at the hip in terms of management, so I think that internal dealings at Microsoft were part of the downfall. I have no idea what happened, but in the bigger picture at that time, Microsoft was finally learning to do things a better way with ASP.NET MVC. For their constituents that may have been a better investment.
Plus, now you have Python for .NET[0] and similar projects that allow you to seamlessly integrate CPython into your .NET program. This gives you the best of both worlds and negates a lot of the value of a dedicated .NET Python implementation.
It also turns out that a lot of popular Python libraries have dependencies on C/C++ code, so there were attempts like IronClad to provide support for these, but it wasn't as easy as CPython. There were benefits like the CLR being able to handle some workloads better than CPython with its GIL, but there are expectations in some libraries that it's CPython running the code.
Startup performance also takes a hit due to jitting, so IronPython had to implement some tricks to make it run scripts fast on the first run. This is a pretty common case.
Then you add in compatibility and testing with frameworks like Django, and balancing that against further development of the core. Even if you support these frameworks, you may not be able to support some of the libraries and tools that these developers coming from the open source world use, so their experience can be soured and the project appears to be more of a science project. That said, IronPython can excel in niches, such as adding scriptability to your .NET app. But that's not going to take over the world.
These problems also applied to IronRuby. Both of them seemed to be joined at the hip in terms of management, so I think that internal dealings at Microsoft were part of the downfall. I have no idea what happened, but in the bigger picture at that time, Microsoft was finally learning to do things a better way with ASP.NET MVC. For their constituents that may have been a better investment.