Everything started with AWT in JDK 1.0. It came with JDK 1.0, and it used (actually uses - is still there) native widgets for rendering. I still remember the excitement, as it was introduced around 1998 (with JDK 1.2). Everyone was excited, although even the JTextFields weren't rendered correctly. Swing took the opposite approach - it rendered the components itself - so it was somehow OS independent. Only about three years later Eclipse was introduced with the SWT. It took similar approach to AWT - because of responsiveness problems of Swing and the native look and feel. At the time it was a viable solution for a given problem (although e.g. the performance of other Swing apps was really good). These days the responsiveness of Swing is just phenomenal (just ask IntelliJ / Netbeans users about it :-)), and Eclipse (forms) looks very different to the native Windows applications (Outlook, Office, OneNote etc.). The new platforms like Flex, Silverlight, even Java FX do not even try to achieve a perfect, native, look and feel - many nice demos just look totally different (which can be a good thing).
A native UI toolkit is harder too maintain for different platforms, because you have to test different operating systems (32 and 64 bits), and emulate some widgets, since they are not available for every given platform. So there is more effort to achieve the same goal (a decent toolkit). Furthermore SWT can only wrap existing native widgets, so the usable API is somehow limited. It's not always fun to work with it. Just ask a developer (after a beer) with SWT / JFace experience, whether he reall enjoyed it. You will get interesting answers :-).
Regarding the maintanenance overhead and portabilities issues - it remains really interesting question. Would e.g. Eclipse start with SWT again - or provide a lightweight approach?
NEW workshop: Building HTML 5 Applications With React.js
On demand workshops: Java EE 7 Bootstrap, Effective Java EE 7, Java EE 7 Testing and NEW: Java EE 7 Microservices are available for streaming