I think elements like scrollbars remaining visible serve a useful purpose of their own. I don't just mean scrollbars in this case depicting the location in the scroll, either, but instead offering a fully predictable interface that looks the same and doesn't depend on state. Elements like scrollbars only appearing when needed- expanding when you hover near them, for example, removes some of the predictability of the interface. If you have elements all over a UI that only appear "when needed" it starts to become a bit of a circus show, IMO; ribbons or toolbars or menus that only appear when you press alt or hover near the top of a window; scrollbars that only appear when you either scroll or move the mouse near the scroll elevator area, etc. It's some of the same push that has removed titlebars from desktop UI. Programs like Chrome spearheaded effectively taking over that area, because it's a "waste of screen space", But it's not, that screen space was used for a predictable, known UI element that used to be fully expected on all desktop UI Window elements. It's sort of like how we have with writing a predictable convention of words on a page to have margins on the left and right. If that followed the way UX has gone we'd have dismissed page margins as "wasted space" and all text would have 0" margins and run all the way to the edges of the page and we'd pat ourselves on the back for "using page real estate" more effectively.

I do think hiding things can be over done, but it's rare that I have found the lack of a title bar problematic. Most apps don't actually remove it, they just decorate it to match their UI. It still has the standard buttons and can be clicked to drag the app around.

"compare something like Swing's JTable to WinForms' DataGrid"

Do you actually mean the DataGrid? Because the WinForms "DataGrid" was deprecated in 2002 with .NET 2.0 which added the DataGridView. The software I work on is Windows Forms and I can't say I've had any issues like you describe with the DataGridView. I was able to create a control derived from it that does all the heavy lifting for customizations(Visual, interaction, cell spanning, etc.), of which we had a lot. Enough that we were exploring third party controls, but found we would have to customize those ourselves anyway, so I just wrote my own control based on DataGridView to save us the licensing.

WPF had it's own DataGrid control from the start, though I can't comment from experience on it's versatility, I'd assume given WPF's nested-content approach it is surely at least more flexible than the DataGridView.

Yes, I mean DataGrid. .NET 2.0 wasn't released until October 2005 so I think your remembrance of dates is a little bit off (understandable: it's now a long time ago).

In any case that didn't really matter. In mid-2004, when I started, the company was still targeting .NET 1.0 for all apps because it meant we could guarantee customers would have that runtime installed on their machines without the need for another dependency. The business model was download -> try -> buy so we wanted as little friction as possible and having a newer version of .NET that might require another download and install wasn't worth the dropout rate we'd experience.

That being said, .NET 1.0 also meant we were using Visual Studio.NET 2002 which was... incredibly painful to work with. I'd come from the world of IntelliJ IDEA which had all manner of code navigation, inspection, refactoring, and testing functionality built in. Not to mention Java already had generics and a much better and more comprehensive framework class library and more mature OSS scene covering whatever was missing from that. .NET 1.0 and VS2002 had none of it and, I forget, was it that VS2002 had no extension model or was it just that ReSharper didn't support it? Either way it felt like stepping back into the mid 1990s and I wasn't happy.

Eventually, sometime in summer or autumn of 2005, I managed to persuade leadership that at least allowing us to use .NET 1.1 and Visual Studio.NET 2003 would be a good idea, and would enable us to use ReSharper, which at least brought us on par with IntelliJ IDEA circa 2003 or so. I can't remember but it might have been that .NET 1.1 had been rolled out over Windows Update or enough service packs for Windows 2000 or Windows XP that we deemed the likely loss of purchases to be negligible.

Our first products developed with .NET 2.0 we didn't start working on until the back half of 2006 and this was really only because we were developing products that plugged in to SQL Server Management Studio which, again IIRC (long time ago), was based on the Visual Studio 2005 shell and required .NET 2.0.

We were always lagging on .NET versions because we wanted to make sure someone could just download, install, and run our products without needing to do anything else.