Absolutely not, but also yes/maybe. No as in: the engine shouldn't parse COLLADA files. But yes/maybe as in: that doesn't mean the engine can't load COLLADA files at runtime.
IMHO, data processing should be moved out of the engine runtime and into the toolchain. This greatly simplifies the engine runtime, which keeps it flexible/maintainable.
If you want to support some extra file format, it's of no concern to the engine runtime; you just add that file loader into the data processing part of the code-base, which is completely decoupled from the engine runtime.
I think it more depends on whether there is a direct practical consequence of supporting or not supporting a given file format.
so, the question isn't so much about whether or not a person can or should be able to load COLLADA, but more what might be the tradeoffs made based on whether or not they decide to support COLLADA, or if they do, whether it is a good idea to load it at runtime, ...
for example, requiring an external library dependency, or being too much of a hassle to implement, would make a case for not supporting it;
whereas, it performing too badly to be worthwhile loading it, more makes a case for not using it (but whether or not the engine can load it, is not nearly so relevant: if it isn't used, it may not cost much either).
I guess it also depends some on how a person sees the role of their engine as well.
in the latter case, how hard it is for end-users to run and administer servers, put up contents, ... may be a bit more of a concern.
but, for other kinds of uses, this may not make sense.
for example, you probably wouldn't want to do a big single-player RPG this way, ...
likewise, for something like an MMO, it may make sense for much more of the processing to be on the client end, mostly as running all the logic on the servers could require a lot more costs due to needing a larger number of beefier servers (granted, the server "could" probably just hand the clients a big glob of bytecode or similar for it to play with, and maybe add in some "tamper protection" features, or mechanisms to hinder client-side modding, ...).