Changed the database column to LONGTEXT on test system and achieves the objective without any obvious issues.

ALTER TABLE #__fields_values CHANGE value value LONGTEXT;

See this plugin
https://github.com/brainforgeUK/plg_fields_bffile

if memory serves me correctly querying a longtext field has performance issues

True, but then why are columns introtext and fulltext of table #__content LONGTEXT ?
The current configuration provides an unacceptable constraint on usability.
A compromise might be to have two types of fields. As existing plus a long field feature.

I don't see this being something that we're going to choose to do anything with. If you're storing that much custom field data then you are almost certainly needing a CCK or you're own table to store data in depending on what your doing

The current implementation is inconsistent with columns introtext and fulltext of table #__content
The current configuration provides an unacceptable constraint on usability.
Using CCK adds an unnecessary level of complexity.

If you are putting that much text into a custom field value then honestly I would say you are doing something wrong and need to be using your own database table.

The introtext and fulltext columns are the way they are because they are designed for entering full text articles. In that context, it would not be acceptable to limit to 65535 bytes (which includes all the HTML and shortcodes for plugins to dynamically alter content). That is not the same use case as custom fields and using the argument "but this column is this long so others should be too" is a non-argument.

I have PDF documents for the data of typically less than 1MB.
The article permissions provide all the security needed.

If people want to use it for videos etc of 1GB or more then, true, they should be considering an alternative. I cannot see a reason for not changing the database to LONGTEXT.

Someone just do a pull request lengthening all of our core fields to the max length for the stored data types and be done with it. That way we can once and for all put a stop to these "database is limiting what I can do" issues.

You are putting the contents of a pdf inside a field?

if memory serves me correctly querying a longtext field has performance issues

No performance difference between "TEXT" and "LONGTEXT" except it needs 2 bytes more in the Database field. There is only a performance penalty (or gain) between "(VAR)CHAR" and (TINY/MEDIUM/LONG)TEXT.

This is the site that started this...
https://lifelineromania.org.uk/stories-newsletters/newsletters

I think tomorrow I'll put a pull request in for this one column.
I'll leave other columns hinted at by mbabker to those affected by them.