The problem I see here is that using ReadLine to load an array, you are reading one line at a time anyway. Then you are processing one line at a time from that array, based on this comment: "Some records and/or fields are ignored, others are modified, line by line as they are read in from the array using VBA."
Why use the array at all? It seems as though it would buy you very little and it will cost you a bunch, because you now need TWO huge chunks in memory at once, once for the array that contains a bunch of strings and once for what gets loaded to the table (which ALSO is a bunch of strings), because the way Access stores things is to have pointers to records that are stored.
Because of virtual memory issues, even with split front-end and back-end, you cannot have more than 2 GB for the FE and 2 GB for the BE - but if you have a non-split DB you STILL won't get a full 4 GB of virtual memory. Even if your system has at least 8 GB of RAM, you cannot exceed 4 GB of virtual space because internally, Access (even the 64-bit version) doesn't take advantage of extended addressing for data structures. (It might do so for library calls, but we can't be sure how that affects virtual memory size.)
What I think is happening is that your string workspace is also getting eaten up pretty badly because of the way string processing occurs. When you do the code to read in a line to your array, do you directly do a readline into an array row or do you do a readline to a string and then store it in the array? THAT choice would also make a big difference if it is what I think it is, i.e. the "heap" used for string processing.