They are most likely deprecated at best, obsolete/wrong at worst, but I'm not fully familiar with the new Entity translation API and code, nor with the code in that field.multilingual.inc file even in D7.
In other words: feedback and help welcome from @plach / @Gabor / @fago :-)

At least it seems that since base fields can be translatable too, those functions have no business
a) being in field.module
b) dealing with "configurable fields" only

field_available_languages()
"Collects the available language codes for the given entity type and field"

field_available_languages()
"Collects the available language codes for the given entity type and field"

This is meaningfully used only by field_invoke_method/field_invoke_method_multiple, where I think we can safely replace it with an inline check for field translatability + EntityInterface::getTranslationLanguages(). My current feeling is that the whole D7 approach of dealing with language at field level is obsolete in D8, where we have the notion of entity translation. Once we are able to move all the field_attach_* functions to entity controllers, we should no longer need to know field language in most scenarios.
I think it should be safe to remove the alter hook as the main use case behind it was supporting language of parts, which @fago suggested to support through a dedicated field item property.

field_content_languages()
"Returns available content language codes"

This can be safely replaced by a call to language_list(Language::STATE_ALL), which is how it is currently implemented in D8 btw.

Since we no longer have the notion of translation handler, we can simply rely on the 'translatable' property of the field definition. We have an issue for the details: #2018685: Remove field_is_translatable().

field_has_translation_handler()
"Checks if a module is registered as a translation handler for a given entity"

Totally obsolete, it should already be deprecated. To be removed ASAP.

field_valid_language()
"Ensures that a given language code is valid"

A small utility function which should turn less and less useful as soon as the migration to the Entity Field API proceeds.

field_language()
"Returns the display language code for the fields attached to the given entity"

field_language() :
- field_get_items(): already deprecated, and was really related to the old "$node->field_foo[$langcode]" syntax, so should be removed here as well.
- field_view_field() / field_view_value(): being taken care of in #2134887: move field_view_field() / field_view_value() to methods
- a couple docs / @see here and there.

TranslationWebTest still has warnings, it seems that ContentEntityBase::getTranslationLanguages() hits cases where $this->translations has entries where $translation['status'] is not set.
@plach: help welcome here :-)

All the old function usages are converted to the new API and the removed test is just obsolete now: the new logic is already covered by the Entity Translation API tests.

The removed hook was never used AFAIK, as no UI was implemented in contrib to support language of parts. Moreover in Prague we agreed that to support that a composite field carrying the field content language would be better suited.

Raising to beta blocker per #2061107-9: Remove deprecated procedural functions in Field API, since this is a requirement for it. Note that this patch actually does remove the field_language() and field_valid_language() functions, counter to the request in #2061107-9: Remove deprecated procedural functions in Field API, but:
a) The patch that got RTBC'd was posted here prior to that request, and
b) I don't know if it's possible to leave these functions in as wrappers to anything and have them be functional in a way that a caller would expect, since the entire concept of these functions is nonsensical with D8's entity translation API.