As always, each takes whatever technology likes to work with and uses it. Here are my two cents regarding the usability of the three technologies.
First of all, the browsers have a CSS parser / interpreter / renderer, so CSS files can be used straight in any HTML project, which does not apply for Less or Sass. In order to use them in HTML projects you would need to have a compiler which compiles the files (Less or Sass) in a CSS file.
Somehow is a trend now to use the more sexy, and at the same time complex, Less and Sass everywhere even when it does not make sense to add the extra effort in compiling those files. Sadly it is now also a requirement for every Front-end developer on any low level job. From my years of work experience I can say that I can live long, well and happy without ever needing Sass or Less, you just need to know your code and apply it in a way it has full flexibility. But this is only me being lazy to compile stuff to get whatever I can write anyway. For me is like some developers wanted to look more developers than the others, but let me tell you where each one is best suited (from my years of working as a developer).
The power of Less and Sass
The biggest argument in using one of them is that you can have references, well, they are like any programming language variables, so once you change the variable value, all the elements who refer / use that value will change too. BUT you can do it in CSS too, so no biggie.
Mixins - here is what I was talking about developers who want to look cooler than others, because in object-oriented programming languages, a Mixin is a class that contains methods for use by other classes without having to be the parent class of those other classes. Sounds complicated and rocket science, so painting front-end pixels should be done only by highly skilled programmers. It is not so complex as it sounds at least in Less or Sass, where a mixin is defined as a class selector: @mixin .whatever { } and inside there are defined properties and value pairs, which later are called in a class with: include: .whatever
Where I see the power of Less and Sass, is in the logic operators part, if you really built an UI which requires functions, loops and crazy math on the CSS side, then this is the way to go. But where you would need that for a simple app / website?!?
Well, if you do some crazy UI which needs to adapt colors based on some other user-generated colors, which at run-time can be heavily modified and without any constraint, but the things inside should behave in a certain way - then you need Less and Sass. Although I never seen things like this in real life.
Another right usage is when you create a theme but you want to create more color schemes based on that theme - although can go as easy with the "old" CSS too.
The power of CSS
First, you do not need to compile, and what you write is what the browser sees. You can use variables too, so no biggie (at least for the new browsers), and where I find more pleasant to work with it is in the inspector where I get the CSS line and change it, reload and good to go. For the less .... well ... first I need to see where in the less file is that class defined, then look up in the sea of includes and references to get down to the line I need to modify, then recompile, upload the CSS again on the server ...... I already wasted half of the day.
If you have less computational needs, the good ol' CSS can handle them well, variables too so for simpler UIs is sometimes easy to go the CSS route.
So, as you see, is again a "case by case" decision, sometimes you need to go for one solution, sometimes for the other. Do not go for one just because is trendy! If you would have to do a quick prototype for whatever interface, why reinvent the wheel and work more when you can get by with spaghetti code, hard coded things and simple CSS. Anyway the prototype goes to trash after a manager, decision maker or whatever person had seen it and agreed on going to that direction, or changed everything, so you need to build a second prototype anyway.