Seems like that would invite armchair engineering like you seen in HN comments. “Couldn’t you just do the easy and obvious thing?” The answer is probably a long no and the creator had your thought already before realizing the true scope of the work.
I recently learned this because I was asked this precise question and basically had to drudge up all my two-quarters-ago research that was the answer to this question. My answer to their question was "yes we could do the easy thing, but..." and everything trailing the "but" is a very long string of small points that add up to something that tipped the scale (at least in my and several other folks opinions). But without that laid clearly out they thought I was just over-engineering for the sake of job security or something like that.
Letting people know why is two fold. Not only does it keep them from relearning the 1000 edge cases you discovered in the school of hard knocks, sometimes technology changes and something that was a hard limit no longer is.
This form on "collective design" usually uses a confrontational form of rhetoric, but the exercise is very much collaborative.
Ideally, if as others have suggested, you've already worked through that question and documented it, you can just refer to that documentation amd move along.
If you haven't documented it, it's a good reminder others may have the same question and answering it will either lead the to the same conclusion or other questions you did not think of.
"Could you do the easy and obvious thing?" means the same thing, I don't see how it makes a difference.
This way proposing xyz as a solution is positive not a negative.