While this doesn't have to be the case, in theory the DMP and DIT can be orthogonal, since leaking data from the DMP is done after-the-fact on caches that might have been populated from code running in constant time. More generally, you can't really know whether such effects are eliminated or not, because DIT specifies some architectural level of "things take the same time" and doesn't actually tell you more about what is going on in the chip. If Apple mistakenly thinks that the DMP is actually not sensitive, and they forget to wire it up to DIT, then you'll be stuck.

So, what you are saying is that you believe the authors were incorrect when they stated "We observe that the DIT bit set on m3 CPUs effectively disables the DMP."; like, your response to my question is (effectively) "I don't believe that quote"?

My response to your specific question is "I believe them when they say that but there is no need for this to be true, and in fact apparently Apple didn't do them in older chip revisions and I'm not sure that is a bug". However I do believe the authors were incorrect when they said "there is no way to disable the DMP on M1 and M2" (surely not involving DIT).

No one claimed it needed to be true, merely that it is true: if we believe (as you claim you do) the first part of the quote, Apple clearly decided at some point -- maybe due to the dawning realization of this very kind of attack (even if the organization didn't model it as such) -- to make DIT also (if saying such makes you feel better) disable this feature, at which point this mechanism is available to userland... which you claimed it would not be (which honestly doesn't make sense anyway to assume as nothing prevents a new bespoke M-specific mechanism / register / whatever--even if it were undocumented!!--from being available to userland).

Apple typically does not make these kinds of things (namely, special Apple silicon stuff) accessible to userland. I think they probably have some specific agreement with ARM to not do it.