What would that space be used for? I can see two possible approaches. One is for the window to dynamically change its width, which might be quite disturbing. The other one is to have some more room for the actual terminal emulation. This latter one can practically only work for VTE-based emulators that don't install geometry hints (such as Termite). Note that depending on the graphical theme (scrollbar's width) and the font size, I guess typically you'd get 1 more extra column if at all, maybe under some IMHO rare circumstances 2 columns.

There are two ways a scrollbar can be "useless", that is, scrollback buffer is empty.

One is the terminal emulator's "normal screen" at startup (before a screenful of data is produced), or after a reset or similar operation. The other one is the "alternate screen" mode. Typically fullscreen apps (vim, weechat etc.) switch to this mode. The alternate screen does not have a scrollback buffer.

Currently I believe a VTE-based app can tell when the scrollbar is unusable (that is, either of these mentioned two cases is present), but cannot tell these two cases apart.

I'm not sure if hiding the scrollbar in the first case would be useful, I'd guess it's more misleading. And depending on the strategy for hiding/showing the scrollbar, it might result in the terminal emulation area shrinking by a column after the first pageful of data is produced, causing it to rewrap lines etc., which may not be a nice user experience.

I'd guess it's better if the scrollbar is only hidden in the alternate screen mode. This requires explicit support (signals emitted) from VTE. Moreover, most likely a heavy cleanup is desired for VTE's quite messy scrollbar handling, since currently updates to the scrollbar's parameters are not always atomic, e.g. bug 709089 might block this feature, I don't know. The fact that VTE's probably going to work around a GTK+ bug 769566 does not make it cleaner at all.

Also note that VTE would perform rewrap-on-resize operation back and forth on the contents of the normal screen, which might be expensive if there's a giant scrollback, and may in some rare cases slightly mangle the contents (e.g. around TAB characters). We might think of a solution where the normal and alternate screens inherently have different sizes, but that just sounds way too complicated.

Let's also note that certain apps, including vim are known not to handle correctly if they receive multiple resize events quickly after each other, due to a race condition. A similar race condition may easily result in many apps not properly starting up if a resize event is received during their startup, which would happen with this feature.

So, changing the terminal's size is quite problematic, IMO not worth it going for, for the benefit of typically 1 extra character column. Changing the window's width might probably be a better approach, if Termite can do it for non-maximized/fullscreen windows only, and more importantly, in a way that doesn't result in VTE resizing back and forth.

Yet another, probably significantly cleaner and more elegant approach could be to (optionally) use an overlay scrollbar, as (optionally) done by e.g. Tilix and Roxterm. Overlay scrollbar is clever enough to only show when there's scrollable content, and only when the mouse is hovered over.

Yet yet another workaround on user side could be to theme the scrollbar to be narrower. That's what I do :-) I'm using Ubuntu with Unity 7 desktop and Ambiance theme. I have these in my ~/.config/gtk-3.0/gtk.css for a narrower scrollbar in gnome-terminal, sure something similar could work for other themes and for Termite too:

terminal-window scrollbar.vertical slider {
    min-width: 5px;
}
terminal-window scrollbar.vertical {
    margin: 0px;
}

This scrollbar is thin enough for me not to worry about wasted screen real estate.

Although the benefit would only 1 or two columns, I'd still call that a win if the implementation would be relatively simple. But it looks like it isn't.

CSS does indeed improve things (new vs default)

.termite scrollbar.vertical slider {
  min-width: 3px;
}

.termite scrollbar.vertical {
  margin: 0px;
}

Not exactly what I had in mind but good enough for now, thanks for the detailed answer by the way.

Just for the record, I'm not Termite's developer. Overlay scrollbar might be a simple and viable idea for him to consider, maybe let's keep the bug open until we hear his take on that? :) Also I'm wondering if you could try this option in Tilix or Roxterm, just to see if you like its overall behavior?

For Roxterm the scrollbar looks like the default Termite one and I didn't see any options to change that.
Tilix looks quite nice. The scrollbar works as an overlay and hides itself after ~2s unless mouse cursor has moved. It also correctly hides the scrollbar completely in vim etc.

Maybe you'd need a newer Roxterm, dunno. It's under Preferences -> Edit current profile -> Scrolling. Anyway, it's irrelevant since you could try it out with Tilix.

Now that you've confirmed that you like this behavior, I'm also curious what Termite's author will think of this.

PR #618 adds the ability to set overlay scrollbars. There is also the possibility of setting the policy to GTK_POLICY_AUTOMATIC, which does exactly what rhssk wanted, but I've had issues using top with that.

Feel free to comment on the PR

Termite is obsolete. Please use Alacritty instead. See https://github.com/thestinger/termite#termite-is-obsoleted-by-alacritty for more details.