No such scenario exists. The STM interface was deprecated because it should not be used (the reason being that it does not accomplish what it set up to accomplish - which is to provide thread safety, and actually kills concurrent performance).
If a servlet implements this interface, you are guaranteed that no two threads will execute concurrently in the servlet's service method. The servlet container can make this guarantee by synchronizing access to a single instance of the servlet, or by maintaining a pool of servlet instances and dispatching each new request to a free servlet.
Note that SingleThreadModel does not solve all thread safety issues. For example, session attributes and static variables can still be accessed by multiple requests on multiple threads at the same time, even when SingleThreadModel servlets are used. It is recommended that a developer take other means to resolve those issues instead of implementing this interface, such as avoiding the usage of an instance variable or synchronizing the block of the code accessing those resources.
So it basically just kills the concurrency without giving you much benifit. I wonder why it was put there is the first place.
When the servlet API was initially being worked out, there were a number of things that people thought would be a good idea for one reason or another.
I think the STM was put in because the vast majority of programmers had only worked with "desktop" style applications where there was only one user. Understanding the consequences of multiple simultaneous requests is quite a big jump from single user programming and the single thread model was there as a sort of mental aid if you were new at server side programming.
Some of the other original ideas provided for various ways to share information between applications - these were found to create big security gaps and are now deprecated.
Best practices for servlets and JSP have evolved a LOT in the years since my 2001 book (which Paul Wheaton helped with - thanks again Paul)