There are two kinds of software written more than 12 months ago: legacy code and failed products.
From your point of view, Backbone isn't a particularly trendy framework, and doesn't appear to be as actively developed as the examples you gave. I don't really know anything about it, but would be inclined to agree; I certainly wouldn't spend my weekends learning it, based on what I've read as I've been surveying the front-end ecosystem trying to decide on a framework myself.
However, from your employer's point of view, they have a product that makes them money, some of which they use to pay a developer in order that that product will continue to make them money. Their only interest in investing in your education is for the value that your increased skills will add to the company. That's how business works. If the work isn't what you want to do, that's an argument against taking that job, not an argument against having to maintain the code.
If whatever service your site provides persists into the future, there may well come a day when you migrate away from backbone. That process will be time-consuming, and may bring you perilously close to the big rewrite of death_. _Your boss is not going to sanction this change based on how backbone will appear on your CV (and hence improve your bargaining power for salary rises or attractiveness to other companies). Such a big investment of business resources will only be the result of a business decision. A decision like that will only be made when it becomes cheaper to upgrade to something newer than it is to maintain the status quo. When they no longer release security patches, leaving you exposed to some vulnerability a script kiddy can find scanning AWS. When you can no longer find libraries that have the functionality you need that's compatible with your existing codebase, so you waste hours reinventing the wheel. When backbone as you know it has been dead for so long that no-one can be found on stack overflow who remembers it. If none of these things apply, it barely even counts as legacy code.
If it makes you feel any better: In around 2010 Rails developers were hit with a double whammy of a new Rails version (3.0) and a new Ruby version (1.9), both of which introduced majorly breaking changes compared to their predecessors. It took 4 GitHub engineers 6 months to upgrade their (admittedly large) codebase. If you read the article, you'll see the kinds of problems I'm describing that forced them to make that investment. Some companies never even made the switch; one company was contracted to make RailsLTS, basically continuing to release security patches to Rails 2.3, and they're still selling it today.