How does this compare to LTS from Canonical/Red Hat?
Ubuntu has a LTS release every 2 years, which is supported for 5 years. FreeBSD will have a release every 2ish years, which is supported for 5 years.
How easy is it going to be to keep up with the changes between the minor releases?
It's already relatively straightforward by using freebsd-update, but work is underway to simplify this further.
What guarantees does the community have that driver modifications/fixes are not going to get stuck in -CURRENT or the next major release only, or have to be manually back-ported?
None. This is, after all, a volunteer project; if nobody is interested in backporting a driver, it isn't going to get backported. Also, from time to time there are new devices which require significant changes to the underlying kernel architecture (video drivers and virtual memory come to mind, for example), and those are often impossible to merge back because doing so would break internal interfaces used by third-party drivers.
I understand that major devices will be impossible or difficult to merge back, especially if there are invasive changes. In the past though even relatively simple changes were not MFC'ed until someone asked for it, and once MFC'ed it took a long time for it to appear in a point -RELEASE. Tracking stable/ isn't for the faint of heart, and especially isn't for those of us that want to do binary upgrades.
Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable? Rather than some of the 8+ months that have happened in the past between point releases?
even relatively simple changes were not MFC'ed until someone asked for it
To a certain extent that's always going to happen in volunteer projects. That said, at least on the server side, the "ecosystem" of FreeBSD-using companies with committers on staff is expanding, and they're doing an increasing amount of this sort of maintenance. The topic of how we can make sure important MFCs happen has certainly come up.
Will this change in the support policy allow point -RELEASE's to be made more often, thereby more closely tracking changes on that particular branch of stable?
Maybe. Certainly there is significant support for doing more frequent point releases; but some of the reason they have been so slow lately has been due to operational issues (aka. re@ juggling too many balls at once) so these policy changes aren't going to have a dramatic effect overnight, but they might contribute to things improving.
Given the limited resources available, what are you expecting to occur? Why would they dedicate staff to back porting drivers that may literally never be used? If the person implementing the driver doesn't personally have a need to run it in an older version of the OS, they aren't going waste precious time back porting it just for the sake of back porting it.
In the case of drivers, a lot depends on the specific hardware. Some drivers are written by employees of the hardware manufacturer, some are written by employees of companies using FreeBSD, and some are written by interested volunteers.
Hardware vendors have an interest in supporting whichever FreeBSD versions are of interest to their customers, and often merge to all supported branches.
Ubuntu has a LTS release every 2 years, which is supported for 5 years. FreeBSD will have a release every 2ish years, which is supported for 5 years.
How easy is it going to be to keep up with the changes between the minor releases?
It's already relatively straightforward by using freebsd-update, but work is underway to simplify this further.
What guarantees does the community have that driver modifications/fixes are not going to get stuck in -CURRENT or the next major release only, or have to be manually back-ported?
None. This is, after all, a volunteer project; if nobody is interested in backporting a driver, it isn't going to get backported. Also, from time to time there are new devices which require significant changes to the underlying kernel architecture (video drivers and virtual memory come to mind, for example), and those are often impossible to merge back because doing so would break internal interfaces used by third-party drivers.