Some taxonomies are treated specially in the API, such that they have a rest_base endpoint prefix that is never published via the taxonomies endpoint. Example: Tags.

The taxonomies response for Tags looks like this:

{
"name": "Tags",
"slug": "post_tag",
"description": "",
"labels": {
    "name": "Tags",
    "singular_name": "Tag",
    "search_items": "Search Tags",
    "popular_items": "Popular Tags",
    "all_items": "All Tags",
    "parent_item": null,
    "parent_item_colon": null,
    "edit_item": "Edit Tag",
    "view_item": "View Tag",
    "update_item": "Update Tag",
    "add_new_item": "Add New Tag",
    "new_item_name": "New Tag Name",
    "separate_items_with_commas": "Separate tags with commas",
    "add_or_remove_items": "Add or remove tags",
    "choose_from_most_used": "Choose from the most used tags",
    "not_found": "No tags found.",
    "menu_name": "Tags",
    "name_admin_bar": "post_tag"
},
"types": [
    "post"
],
"show_cloud": true,
"hierarchical": false
}

An intelligent guess might use the slug as the Tags endpoint prefix, but alas, Tags use a hard-coded rest_base property ("tag") instead. Category also has a rest_base, but through sheer luck it is the taxonomy's slug ("category").

This means there's literally no way to logically map the Tags taxonomy to the Tags endpoints. Yes, the routes are published at the API index, but that's simply a flat listing of "here's a bunch of URLs that probably have some data." There's absolutely no logical association between the Taxonomy and its endpoint URLs.

The rest_base property should either be included in the Taxonomy response, or it should be dropped in favor of simply using the slug -- since that's precisely what slugs are for. I'm not sure what rest_base is accomplishing besides breaking the alignment of data.