There's Splitties Views DSL, and there's Anko layouts. There's many splits, and there's Anko commons.
Let's see what are the differences and why Splitties was built while Anko already existed under full awareness of the founder of the Splitties project.
TL;DR first: Splitties is lighter, more explicit, more flexible and… more split.
To use a View in an Anko layout, in addition to a function for DSL usage, a subclass of it, specially tailored to work with Anko layouts is needed.
Splitties Views DSL does not require such a thing at all. You can just pass the constructor
reference to the view function (e.g. view(::MyShinyCustomView)), and if you want, for your convenience, you can make an "alias function" (e.g. myShinyCustomView()), which can (should) be inline. Consequently, Splitties is lighter, and more flexible.
In DSL fashion, Anko layouts implicitly add any view you create using the DSL to the receiver ViewGroup if any, or set it as a content view if in an Activity.
In the real world, you rarely add a View without specifying the LayoutParams, so this implicit behavior only makes it easier to forget specifying the layout params, and realizing it later, possibly losing time in your development process.
Splitties never adds a View implicitly. You always have to supply LayoutParams to the add function. That also makes creating a View without adding it at instantiation place straightforward.
Anko commons has several extension functions or helpers for Android to avoid some boilerplate. However, you need to have the full dependency even if you use only a few parts in it, which can make your app bigger (before proguard at least).
Splitties, from day one was split (that's where its name comes from). You can use only one module with, let's say, Splitties Intents, but not Splitties Fragment Args. This avoids to integrate what you know you don't need, and helps making your app smaller.