The big hurdles with self-balancing trees is that there can be a significant amount of overhead if implemented poorly. You don't have this issue in unbalanced trees because it's that simple, you insert, then they stay unbalanced.
With that being said, the difference comes down to the input.
If your input is sorted or almost sorted, as the wiki article says, it will result in a worst-case or bad-case tree which can result in the algorithm being worst-case $O(n^2)$ on an unbalanced tree. This is the scenario (almost sorted input) where you would probably want to use balanced trees.
However, if your input is sufficiently shuffled, then an unbalanced tree would still allow the algorithm to run in expected $O( n \log n)$. This is because we would be creating a Random Binary Search Tree. The expected search length to a node would be $O(\log n)$, thus allowing us to achieve expected $O(n \log n)$ for all insertions.
If you're stuck with a poorly implemented self-balancing BST, then perhaps a light-weight unbalanced tree paired with a good shuffle of the input could be more practical for you.
I haven't done it myself, but I would recommend comparing these two strategies via implementation and compare some statistics. It would probably be interesting.