When we shouldn't use Domain-Driven Design approach?
Take those numbers simply as some values based on the author experience (Evans' book was published more than 13 years ago, things have changed since then).
First of all, the thing that (sadly) few devs understand is that DDD is all about a mindset, a way of looking at things. That's it. So you can use DDD in every project, because we still need to understand the domain first, regardless of its implemention. If it turns out the domain is just a bunch of data structures, then you don't need to complicate your life. Especially if you are building a 'dumb' app i.e a UI for the database.
But if you're building an app which needs to understand business semantics (concepts and behaviour) in order to automate things, then it's a different story and all those DDD notions will help you build a more maintainable app.
So it very much depends on your app, and even in that app things can vary a lot. You should first understand the app's purpose, then the domain it tries to represent (if that's the case) and come up with a solution for each use case. In one app, you can have a lot of CRUD stuff and you can be very efficient leaving out many abstractions and you can have a couple of important concepts and use cases that will require a much better understanding and design. It also matters how much you think that the app will change over time. If there are signs it's something that will evolve over time,it might be better to abstract things a bit, but only from a design point of view. The implementation can still be CRUDy at this point.
If you treat a methodology as a group of mindset and concepts, you can use it everywhere because something like DDD is not a 'how to' coding recipe. While it has some specific tools, you, the app designer should decide if they are good for your app.
Simply put, you have to use DDD in order to decide if (the whole) DDD is usable for some parts of your app. But once again, DDD means the strategic approach, the mindset.
It's simply wrong to decide on a solution from the beginning for the whole app. Understand the problems the app tries to solve and use the proper solution for each problem. If in the end everything is just CRUD, then it's ok. It's equally ok if only some parts are implemented using DDD tactical tools, the point is to have the optimum solution for a problem.
In conclusion, learn and understand the DDD mindset (there's a a lot of explanations out there, focus on the design, not on the recipes as they are wrong), avoid considering it a coding recipe and just use it in order to determine the best approach for the app's needs.
DDD is a collection of ideas. When you say, use it, I'm not sure what you are referring to. For example, ubiquitous language is probably a good idea if you are mapping a business into code. Value types can be useful as well.
But ideas like bounded context and aggregate roots? Well, developing in that style will have a bigger cost because the design naturally becomes more complex. And in some problem domains, it is necessary to isolate the domain problem. And that is because the problem is hard. In other words, 95% of systems do not solve hard problems that warrant the cost of complexity.
I like to think of DDD as existing inside a sort of design spectrum.
Something like:
<--CRUD----Active Record----Domain Model----DDD-->
From left to right, these ideas grow in complexity. And you would naturally move from left to right as you are evolving the design of the code. It is good practice to defer decisions about design (architecture) as late as possible. So, you can always start with something on the left and move towards the right.
Vaughn Vernon evokes in his great book his DDD scorecard.
If your application is specifically CRUD-oriented, DDD would be YAGNI.
Otherwise, if your application is really task-oriented, catching a specific intent of the user, DDD might really help you.