You can't both honor a constraint and give an out for it.
Remember OG twitter and someone complained about the 140 character limit. Imagine the reply was "ok fine we'll let you use more than 128 characters, but you have to click an 'advanced' tab." instead of the "be clever" retort we really got from Jack Dorsey. Immediately there'd be no constraint at all, just an annoying step where you had to click an annoying checkbox.
Point being - if the design is intended to be constrained, then it's perfectly reasonable to own that.
I think your example is different, because we are talking about something that would be only my code, should it not be up to me? And even if it was not feasible right now, someone else would write the code to make it possible, for their own project. Twitter is not your product, you are only using it. And it is also possible to do it, so why not document it? That makes no sense. That is akin to security through obscurity.
Also he said "but also leads to decision paralysis for most users", but it does not have to be the case. Default can be whatever you want.
I think you're both right. It's tricky to know when to make something a default and when to make it a constant. Especially when it comes to users, who cannot all be pleased.
I think it would just kill flexibility, making it the default makes more sense to me, and you should leave it up to the developers using your product, but it is entirely up to you, of course. If I were to turn this into a constant, I would document it at the very least in the git commit message.
I think a fun solution to this, and the one I adopted, is to leave these power features in here as easter eggs, so that devs are rewarded for finding them. At least for me, it gives me a sense of the fun and excitement of learning GUI dev during the 90s. The screen resizing functionality can be found by anyone who digs into the code a little.
That sounds fair to me!