Someone care to take a stab at it or point to a resource?
Mixins, together with some other cool D features, like CTFE (compile-time function execution), templates and ability to load external file at compile-time can be used to create DSL compiler which compiles to native code (first to D, than to native, of course).
For example, ctRegex from std.regex  (standard library regular expressions module) uses mixins to generate D code in compile-time out of regular expression (and D compiler outputs native code for regular expression matching).
There is also a PEG parser that works at compile-time (reads external PEG grammar and generates parser code) but I cannot find a link at the moment.
Of course, creating DSL parsers is not the only thing you can do with mixins, but they are surly the first to come to mind..
Some use cases:
- make repetitive code shorter . Think the C preprocessor but after the parsing stage.
- operator overloading is a single template function parameterized by a compile-time string. This more or less requires using string mixins .
-  raleks's comment has better examples .
Overall string mixins feel a bit dirty but you get used to it. D also has "template mixins" which do not escape parsing prior instantiation.
D mixins are neither like Scala mixins nor Ruby mixins.
The idea of Mix-ins is that an object may have several functional components, like say a printer, a logger, maybe some access controls for user privileges, in addition to the actual class bits. Under a mix-in system, you would write a printer mix-in, a logger mix-in, and an access-control mix-in, and then any of your classes can get that functionality just by including them. Adding this functionality is supposed to be literally as easy as adding a decorator in Python, but in order to do this, they usually need programmatic access to the guts of your class in order to insert themselves. That aspect, allowing mix-ins to make programmatic additions and modifications to a class, are what separates them from other styles of OOP like inheritance and composition (those other styles see this as breaking encapsulation, while mix-ins say the components are still functionally independent).
A traditional (inheritance-based) object system probably won't be able to write these services as independent components without meta-programming, and you usually see mix-in libraries written on top of meta-programming systems (a more limited form is also available via multiple-inheritance). They goal is that they provide one of the more common uses of meta-programming, but in a structured and standardized form, since raw meta-programming (and unrestricted multiple-inheritance) has a reputation for going bonkers pretty quickly. Adding it to a stricter language like C# requires extending the language with a tool, not just writing a library.
You are correct though that the "mixins" in this article are nothing like Ruby mixins.
The final matrix-example from the article shows a pretty neat example IMO.