Затем, что приватные классы для каждой платформы наследуются от одного базового приватного класса, который содержит одинаковые параметры для любой
платформы (например, скорость, четность и т.п.).
Но каждая платформа, наследуясь от базового класса привносит свои параметры.

Поэтому метод create() создает экземпляр нужного приватного класса для даной платформы.
Если б не было этого метода, то

C++ (Qt)
SerialPort::SerialPort(QObject *parent)
    : QIODevice(parent)
    , d_ptr(new SerialPortPrivate(this))
{}
 

создавал бы базовый класс SerialPort, а не тот что реально нужен (SerialPort для винды - WinSerialPort).

В смысле?

ЗЫ: и парни, разберитесь досконально в исходниках, перед тем как что-то советовать (это камень к пастору) .

Совершенно необоснованный ничем камень в мою сторону. Я так понимаю b-s-a понял очем речь. При одинаковых именах отпадает надобность в методе create() и впринципе в наследовани. Но это всего другой подход к решению одной и тойже задачи.

ЗЫ: А исходники я конечно смотрел.

Вот короткая иллюстрация:

serialport_p.h

C++ (Qt)
class SerialPortPrivate
{
public:
    // some common methods
...
#ifdef Q_WS_WIN
   //some windows specified methods
#endif
#ifdef Q_WS_MAC
   //some mac specified methods
#endif
#ifdef Q_WS_X11
  //some unix specified methods
#endif
.... 
private:
    // some common data
};

В  файле serialport.cpp будет находится общая для всех платформ реализация методов.
В фалах serialport_win.cpp, serialport_mac.cpp, serialport_unix.cpp будет находиться реализация этих методов для каждой платформы

Ну и наконец

C++ (Qt)
SerialPort::SerialPort(QObject *parent)
    : QIODevice(parent)
    , d_ptr(new SerialPortPrivate(this))
{}

создавал бы все что нужно вне зависимости от платформы.

В качестве примера можно рассмотреть qthread класс.

ЗЫЫ: Чтобы не перегружать serialport_p.h специфическими для платформы вспомогательными методами, их можно вынести в соотвествующее cpp файлы и оформить как статические функции.

2 pastor,
да, я понял твою мысль.
Но, увы, там будут не только платформоспецифичные методы, но и переменные.
Поэтому всё усложнится и загромоздится, если все сваливать в один заголовочный файл.
Поэтому, лучше всё это разделить на несколько заголовков.

Ну так как сделать то?
Я склоняюсь к варианту всё разделить (например, так сделаны Qt4 классы: евент диспетчер и т п.).

Блин, с разделением тоже не все гладко.
Проблема с методами:

C++ (Qt)
bool SerialPortPrivate::canReadNotification()
{
#if defined (Q_OS_WINCE)
    QMutexLocker locker(&m_readNotificationMutex);
#endif
 
    Q_Q(SerialPort);
...
...
emit q->readyRead();
...
...
}
 
bool SerialPortPrivate::canWriteNotification()
{
#if defined (Q_OS_WINCE)
    QMutexLocker locker(&m_writeNotificationMutex);
#endif
...
...
}
 

т.е. если методы принадлежат классу SerialPortPrivate, то этот класс не видит
члены m_writeNotificationMutex, m_readNotificationMutex которые являются платформоспецифичными (для вин це)
и реально находятся в классе наследнике WinSerialPortPrivate.

если же эти методы перенести в WinSerialPortPrivate, то перестает работать макрос  Q_Q(SerialPort); ,
и выдает ошибку на emit q->readyRead();

Вот засада.  

И теперь склоняюсь к мнению pastor-а, чтобы не делать наследование, а впихнуть всё в один заголовочный файл с делением дефайнами,
а уже реализацию оставить в разных cpp файлах.  

ЗЫ: я приаттачил редактированную версию в которой проявляется проблема. (компилить пока на Linux)

2 pastor,
ну так это уже получается что m_data имеет тот же эквивалент, что и engine в исходниках Qt4 для сокетов и пр. классов. Не?
А если это так - то мы же (b-s-a) был против такого деления (хотя я был не против ).
Т.е. через engine бла сделана версия библиотеки 0.4.0 и master ветка.

Кинь, если не затруднит, твой примерчик с приватными данными, применительно к реальной реализации.,
т.е. с набором тех методов и членов, которые ты бы сунул в эти приватные данные.