There have been various real world applications that use splay tree. One of the most prominent examples is the gcc compiler that applies splay tree. There are many other examples. In fact, ACM Kanellakis Theory and Practice Award 1999 was given to Daniel Sleator and Robert Tarjan for their seminal work on the splay tree data structure.
It looks like you have some misconception on the splay tree about its worst performance.
Take the example you have mentioned, where we access a splay tree of $n$ nodes that labelled from $1$ to $n$ according to their level in the tree, starting from $n$ down to $1$. Your intuition indicates "this case would be significantly slower than an AVL tree." Indeed, the height of the tree before and after those search operations is $n-1$. That is, the tree is the most unbalanced tree before and after that search operations.
However, contrary to your intuition, it turns out that case is a showcase of the stellar performance of a splay tree. Although an $O(n)$-time operation is needed to access the first few nodes, the average cost for all search operations is smaller than a constant that is not dependent on $n$ (assuming the usual RAM arithmetic computation model)! In fact, we have the sequential access theorem for splay tree, which says that if you look up all $n$ elements in a splay tree in ascending or descending order, the amortized cost of each lookup in terms of the number of tree rotations is $O(1)$. The proven constant factor, $4.5$, is pretty small.
You cannot achieve such amazing performance with any kind of search tree that keeps intact during a search, including an AVL tree. To experience that phenomenon, you can go to splay tree visualization. Enter $32$. Hit "insert". Enter $31$. Hit "insert". And so on until you have inserted $1$. Then find $32, 31, \cdots, 1$. Observe what is happening.
Once you have that experience, it is not hard to understand that extraordinary phenomenon. After about $\log_2(n)$ search operations initially, the tree becomes almost completely balanced, that is, its height is about $\log_2(n)$. Since that point of time on, accessing each next node will take at most $\log_2(n)$ time. Furthermore, whenever a node that is somewhat far from the root is accessed, the nodes along its path to the root are brought up significantly closer to the root. In the end, the vast majority of the nodes will be found within some constant time.