Why? Suggestion: read the black book, Design and Implementation of the FreeBSD System, by Kirk McKusick et al., it probably explains how ACLs are stored. Educated guess: the entries have to be stored together with other metadata (like ownership and permissions), and for simplicity the implementation says that all that has to fit into a single sector or block. Otherwise updates to the metadata might require updates to two places on disk simultaneously. And getting that to be atomic is hard, and can kill performance.
Your use case is extraordinary; in my experience, typical number of ACL entries is at most a handful. There is a good reason for that: managing ACLs is hard. The reason is a simple scalability argument: ACLs exist for every object in the file system (fundamentally, for every file). That means you end up having tens of thousands or millions of them. Now imagine you have hundreds of ACL entries per files, times many files, and management quickly becomes overwhelming. That's why access control entries are usually written in terms of groups or globally, and applied to directories only or as inheriting ACLs, to simplify things. In your case, you might have a way to manage that complexity, but now you're running into the limitation that what you're doing is highly unusual, and therefore not well supported. Look at that common use case, and it becomes easier to understand why implementing hugely long ACLs is not a priority for file systems.
Have you considered whether evaluating all these entries will take too much CPU time?
