CC: Tweaked 1.109.0 to 1.109.3 removed binary chunk loading support (produced from string.dump)
However on earlier version it was working if used correctly (as stated in #1604 )
Example:

local file = fs.open("my_bytecode", "wb")
file.write(string.dump(function() for i=1, 10 do print("Hello",i) end end))
file.close()
-------
local file = fs.open("my_bytecode", "rb")
local fun = loadstring(fs.readAll())
file.close()
fun()

now it is broken
Removing a good feature for at least some security from outer or unattended edits/reading is pointless, unless good alternative is present, like do not allow reading another computer's file using disk drive by default
To avoid jvm errors, a lua check is needed, for example string extracted from file opened in binary mode get special meta-value that is checked before loading the byte code. If it is not present, throw an error like "Binary chunk is corrupter (Be sure to use *b file mode)"

As I mentioned in #1604, Lua's bytecode is a bit of an implementation detail, and should not be relied on, as it changes between Lua versions. Indeed, in CC:T 1.109 we updated our Lua VM to Lua 5.2, which made several breaking changes to the bytecode format.

#1615 goes into this in more detail, but as part of that upgrade, I made the choice to just remove bytecode loading entirely, at least for now. I definitely appreciate it makes some programs a bit of a pain, but I don't think it's worth the implementation and maintenance complexity.

As far as your specific use-case, I think it's worth mentioning that Lua bytecode is trivial to decompile, and thus doesn't really add any extra "security" or protection over just minifying your code.

this is terrible! you can't just outright remove access to a core aspect of the lua engine, without any hope of polyfills being made. even a handle in the debug global would be better than this "solution". i see that it is a general trend of this fork to break compatibility with the old CC, which, even if for the right reasons, is just terrible! you can't just break existing code like this!

you can't just outright remove access to a core aspect of the lua engine

Yes you can. Easily. And I've seen many implementations of Lua do this.

i see that it is a general trend of this fork to break compatibility with old CC
...
you can't just break existing code like this!

CC:T tries to remain as compatible with old CC as possible, but there will inevitably be breaking changes. It's not a trend, it's just things eventually must change, lest we get stuck so badly holding onto old code that everything becomes spaghetti in a blender. 95%+ of programs will still work with this change. The very small remainder of projects will not, but that's okay because most of those projects are usually outside the scope of what CC is even meant for.

Bytecode is a hassle to maintain (both in security and just in general), and SquidDev only has so much time. I don't blame him for no longer wanting to spend time on maintaining it.