Sorry but no, "that times" are not over yet lcl has a lot of maturity to do at the current pace of things I would say an other 5 years at least.
Yes, I suppose you're right. A good example is the ScrollWindow Win32 API function:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787591(v=vs.85).aspxBack when I ported the Orpheus table (grid) control, this was not implemented on any non-Windows widgetset. Now I see that it has been implemented for most widgetsets, although GTK never got it. In fact, I see that Carbon has two versions of ScrollWindow, one that only gets used if you define NewScrollWindowEx when you build the Carbon LCL (meaning no one has ever used it). And Cocoa still doesn't have ScrollWindow implemented, which probably explains why TStringGrid is only partially function on Cocoa (TStringGrid now uses ScrollWindow too).
So a decade after I ported Orpheus, have things improved much with LCL? Well, not so much for Mac users, but certainly GTK2 was a big step up over GTK (Windows has always been pretty solid).
So what's a user to do? Probably three choices:
(1) Use LCL and hope you don't run into an insurmountable obstacle.
(2) Use a non-LCL approach (for example, Xcode + FPC).
(3) Move on to a non-Pascal tool.
In the Mac world, there are a few hardy souls who went with (2), but I would guess most pass on without much complaint to (3).
Actually, there's kind of (1a) that you can use by taking a page from the LCL playbook. That is, create custom controls for what you need and only implement them for the platforms you're interested in. So, for example, I created TWebBrowser for use with Cocoa. Since Qt4 was easy to implement, I did it too, but currently I'm kind of indifferent to the other widgetsets. After all, all anyone has to do is implement the platform-specific part of TWebBrower to use it with their widgetset, just as "all" a Mac user has to do is implement ScrollWindow and the other bits to use the full LCL.