Imagine a real concurrent scenario where StringBuffer should be used than StringBuilder?

Question 1

The reason StringBuffer is thread-safe is that back in the day when the first version of the java api was designed, people approached concurrency differently than nowadays. The prevailing opinion was that objects should be thread safe - because Java supports threads, and people might use any JDK class in multiple threads. Later, when Java was starting to be optimized for execution time, the cost of those needless synchronization blocks started to become a problem, so newer APIs were designed to not be synchronized. Still later, the JVM started to optimize locks to the point that uncontested locks became essentially free, making the entire decision a moot point.

StringBuffer is still thread-safe, because old code might rely on it being thread-safe. That is far from typical use, but conceivable.

For instance, suppose you were writing a logfile appender that forwards log entries to a central server. Since we don't want to block the caller while waiting for network I/O we do that in a dedicated thread. The other threads would accumulate their log entries in a StringBuffer:

class RemoteLogger implements Runnable, Appender {
    final StringBuffer buffer = new StringBuffer();

    void append(String s) {
        buffer.append(s);
    }

    public void run() {
        for (;;) {
            Thread.sleep(100);

            String message = buffer.toString();
            sendToServer(message);
            buffer.delete(0, message.length());
        }
    }
}

Question 2

The simple answer is NO. IMHO there is no sane situation where you would use StringBuffer instead of StringBuilder or another class. Making StringBuffer thread safe can make your code less thread safe because people mistakenly assume that if you have used StringBuffer you code is thread safe when this is not the case.

If you have used StringBuffer, at some point you have to use synchronized, although where is not always clear to most developers, and I have seen many bugs where this (even in mature libraries) wasn't done or wasn't done correctly. It is much better you use StringBuilder and do the locking enternally, consistently.

Why a synchronized StringBuffer was never a good idea.

is the case that StringBuffer is preferred really existed

There is one use case; you have a library which only accepts StringBuffer in the API. This is poor design for the reason mentioned above, but not library is perfect. ;)

Question 3

Really anywhere when a text buffer might be accessed concurrently.

As an example, how about having multiple writer threads that will be outputting data across a network. In that case maybe they share a common text buffer and just directly write to it and when the buffer is full it can be sent across the network.

Question 4

The following program will sometimes throw exceptions when using StringBuilder, but will never throw an exception when using StringBuffer.

Program:

public class StringBuilderConcurrent {
    static final StringBuilder sb = new StringBuilder(); // shared memory

    public static void main(String[] args) throws Exception {
        int NUM_WRITERS = 300;
        ArrayList<WriterThread> threads = new ArrayList<WriterThread>(NUM_WRITERS);
        for (int i = 0; i < NUM_WRITERS; i++) {
            WriterThread wt = new WriterThread("writerThread" + i);
            threads.add(wt);
            wt.start();
        }
        for (int i = 0; i < threads.size(); i++) {
            threads.get(i).join();
        }    
        System.out.println(sb);
    }

    public static class WriterThread extends Thread {
        public WriterThread(String name) {
            super(name);
        }
        public void run() {
            String nameNl = this.getName() + "\n";
            for (int i = 1; i < 20; i++) {
                sb.append(nameNl);
            }
        }
    };
}

Because StringBuilder (sb) is not thread safe, having multiple threads write data to sb may result in sb becoming corrupted (e.g. unexpected null characters, a word's letters interspersed with some other word's letters). It's also possible for sb's internal state to become inconsistent enough that an exception might be thrown:

Exception in thread "writerThread0" java.lang.ArrayIndexOutOfBoundsException
    at java.lang.System.arraycopy(Native Method)
    at java.lang.String.getChars(String.java:854)
    at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:391)
    at java.lang.StringBuilder.append(StringBuilder.java:119)
    at test.StringBuilderConcurrent$WriterThread.run(StringBuilderConcurrent.java:35)

The following program is identical to the first except it uses StringBuffer instead of StringBuilder. It will never encounter an ArrayIndexOutOfBoundsException.

public class StringBufferConcurrent {
    static final StringBuffer sb = new StringBuffer(); // shared memory

    public static void main(String[] args) throws Exception {
        int NUM_WRITERS = 300;
        ArrayList<WriterThread> threads = new ArrayList<WriterThread>(NUM_WRITERS);
        for (int i = 0; i < NUM_WRITERS; i++) {
            WriterThread wt = new WriterThread("writerThread" + i);
            threads.add(wt);
            wt.start();
        }
        for (int i = 0; i < threads.size(); i++) {
            threads.get(i).join();
        }

        System.out.println(sb);
    }

    public static class WriterThread extends Thread {
        public WriterThread(String name) {
            super(name);
        }
        public void run() {
            String nameNl = this.getName() + "\n";
            for (int i = 1; i < 20; i++) {
                sb.append(nameNl);
            }
        }
    };
}

Whether these programs are representative of a "real world" problem is a fairly subjective question. I'll leave that judgement up to the audience.