Background: the presentation of changes in n3279 only implicitly lists the main actual change:
Functions that don't have a wide contract shouldn't have an unconditional noexcept specification.
This is the cause of most of the changes (so any function with a Requires-clause should clearly not be noexcept).
The reason is described in n3248: you cannot use exceptions to internally test pre-conditions if the function specifies that it is noexcept (since the exception cannot be caught - not even in debug-builds, one of the suggested options in n3248 was to allow a debug-mode to catch them).
So what about conditional noexcept?
The background doesn't explain why a few conditional noexcept without a Requires-clause were removed, but it indicated a general move away from potentially excessive noexcept and n3248 also states:
What are the risks associated with noexcept?
Unfortunately the feature
is so new that there is very little field experience to develop a
coherent set of guidelines. The risk from overly aggressive use of
noexcept specifications is that programs with hidden terminate calls
are produced. The risk of under-specifying noexcept specifications is
that they become difficult to add in a later revision of the standard,
as the noexcept operator becomes an observable part of the ABI.
Thus it seems that keeping a few conditional noexcept wasn't deemed worth those risks, compared to the benefits it would bring.