Mixins, at least in D, can be very useful when you want to do some meta-programming (at compile-time, of course). They basically allow you to generate code at compile time.
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 [1] (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..
Mix-ins are a style of object-oriented design, in the sense that inheritance, or composition, or generic functions are styles of object-oriented design. They all have the same purpose: logically related pieces of code are co-located and encapsulated, and independent pieces of behavior are decoupled. Ideally, the components of your system should have low interdependency, and be easy to combine.
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.
Normally you'd be right, but D co-opts what the rest of the world accepts as having a well-defined meaning pertaining to OOP to instead represent its hare-brained meta-programming paradigm.
I was confused too when I saw this article on Reddit. Turns out that Mixins in D are similar to Macros and not similar to Ruby mixins. Mixins in an object oriented sense (such as Ruby) are very similar to interfaces in C#.
I wouldn't say that Ruby Mixins are not really similar to interfaces at all, since interfaces represent signature to be implemented by the class and mixins represent implementation.
You are correct though that the "mixins" in this article are nothing like Ruby mixins.
Someone care to take a stab at it or point to a resource?