Here is a bit of history and a bit from a programmers perspective of large scale systems. Stick with me. I have a specific answer for you.
At one point, Google thought that exact match keyword domains should rank high. Given the environment, that was true at the time, however, Google temporarily seemed to have forgotten that this could be manipulated and the boost was significant enough that spammers took advantage of Google's idea. Within about a year plus, Google realized the error of their ways and fixed the problem.
Now for the programming perspective.
**Note: I am not saying this is exactly how Google works, but it should be similar enough that this example should suffice. In fact, there are many ways of doing the same thing so please take this with some salt.
Systems that use AI (artificial intelligence), use agents that are smaller programs that are to determine just one simple thing. They answer a question. For example, does a domain name have known terms? Agents can be complicated, but generally only inspect one set of conditions to answer one question.
So when a new domain is added to the database, a trigger would fire off some agents one of which determines if terms exist within the domain name and makes an entry into the index indicating such with weight for the terms within the domain name.
AI systems are highly reliant upon algorithms and metrics. When creating large scale systems, wise programmers build a lot of flexibility into their code. What is commonly done is that any metric or data that is useful and can be captured in code is stored. So as systems grow and are developed, more and more data potential is realized and captured and more and more metrics are stored as well. It is expensive to create this code and if code is no longer required, it is simply turned off with a switch internal within the code and not always edited out. This is not always the case of course. Code is edited and improved over time and large scale edits are sometimes made removing sections that are determined not to be needed in the future. However, sometimes code elements are retained to be repurposed later if it appears to still be useful.
Metrics are a central part of AI. These are a way of making measures that decision tables and other methods use to help make decisions. You can write code that makes determinations on the fly or you can write an agent that does the same thing and stores a metric or metrics that can be used in decision making. It is far cheaper to write agents and store metrics than to write more intensive code that you may need in several places.
Algorithms are rather expensive to create and edit. They act against the metrics that are stored. It is far cheaper to adjust a metric than change an algorithm. Better yet, it is far cheaper to create a weight for some or most metrics to finely adjust an algorithm without editing it. Anyone who has used rolling averages is aware of decay rates. This is an example of the concept. Instead of editing the code, you simply adjust the decay rate to effect the accuracy of the rolling average. Even wiser still, you can freeze the decay rate within the algorithm and use another metric as a weight within your algorithm to micro-adjust the decay rate. It is like doing simple math. 2.0 (decay rate) plus .01 (decay rate adjustment value) allows you to have relatively stable metrics and micro-adjust the effect of the metric when required. This adjustment weight can be stored and changed without going into code and editing it. This is a simple example and you may think it is redundant- why not simply adjust the decay rate? You can. But when you are dealing with hundreds or thousands of metrics, this method becomes invaluable.
Think of it as adjusting a volume knob up or down. Just now you many have a bunch of them.
For AI systems, algorithms can be changed based upon discovery and the need to correct the algorithm. However, most of the time, the algorithm can be adjusted simply by adjusting the metric adjustment weights to effect the outcome if and when the basic algorithm is correct, but the values skew the results. But sometimes the basic metrics or calculation needs to be adjusted. There are often batch style code that takes the agents and applies them. So if an agent is calculating a metric and that code needs to be changed, the batch style code can make system wide recalculations to make system wide adjustments.
In Google's wisdom, they make use of all of this.
Panda was originally created as a batch style process. I am not claiming that I know how Panda works exactly, but it remains as an example. Agents and other code that make metric calculations and decisions were wrapped into a single process that ran quarterly. Each quarter, Panda was adjusted to do two things: one, do a better job; and two, correct mistakes. Over time, Panda was adjusted to be more highly effective and to do a more precise job. Google took input from it's user base and allowed spam sites to exits for a period allowing Google to target examples with their Panda algorithm. These targets then were effected when the next Panda update was released and run. It was reported that Panda was being run more often and could be seen as often as a month or just a few weeks. Today, it may have been integrated into the system. I have not paid attention.
Back to your question.
I cannot say that Google changed the algorithm for exact match domains. It is likely that metric weights were adjusted at the very least to create a new effect. So where values were once used to effect searches and exact match keyword domains ranking them higher in the SERPs, it is likely that several weights were changed, some being reduced and others increased, to change the effect to something more palatable and correct.
So exact match domains no longer jump to the top of the SERPs unless certain conditions exist.
Basic ranking, setting aside exact match domains, will largely trump exact match domain names. Where this is not the case is where comparatively little competitive content and/or comparatively little high quality content is found and you are reaching the bottom the of the matching algorithm. Here, it is possible that exact match domain names might be used. Keep in mind that
description meta-tags, header tags, internal and inbound (back) links, and even content will trump exact match domains. Where exact match domains do perform well are for niche searches that are more rare and where keywords and keyword matches are less likely. Where the competition for a particular term is lower, exact match domains will perform best. This is a sliding scale of course. Your example (ielts) is perfect for this. The first result is www.ielts.org. However for a highly competitive term such as SEO, far better performing results will trump seo.com which exists.
Given this, and since your keyword ielts exist as ielts.com, you can chose to use the term in your domain name. It might be a good idea in your case. However, for you to gain exact keyword match over your competition, you must build a site that is superior to ielts.com and any other site that uses the keyword. You will have to go back to good ole' fashioned SEO for that. In fact, you would have to do that anyway. But in your case, being your keyword is a niche keyword, it is more likely that an exact match domain will have an effect and bubble to the top of the SERPs.