some have said that paper prototypes are a waste of time.
what i have observed is that paper prototyping is extremely useful when you haven't decided how you want things to work. that is, if you are having the discussion "wouldn't it be great if we could 'fling' this doo-dad in order to dismiss it?" and then a minute later you have a piece of paper that you can literally fling across another piece of paper or perhaps, an actual ipad.
in about a minute, you can do "wacky" things like prototype something akin to "what if you crumpled the item with a pinch gesture when you were done with it?" or "what if you swiped successive items, like sheets of paper, you know, like from that production company back in the 80s at the end of all the tv shows." and then you do it and you say something like "oh, yeah, ok let's not do that"
and then later that afternoon, once you've settled the "dispute" then you can spend the next few hours prototyping the hell out of whatever it is you thought was a good idea. that's when you bust out the quartz composer/html/js/react/cloud/mp3 ripping/mesh network/interface builder/drone snack delivery/framer/etc.
and if that feels right, then you can go ahead and implement that in your web app or mobile app or whatever given the constraints of your api/scheduling/nosqlbane/datastore/frameworks/etc.
the danger, the thing you're fighting, is that you spend, up-front, a day or two or ten realizing what could legitimately have been discovered by a piece of paper sitting atop your ipad. it has taken me a comical amount of programming to realize when a paper prototype is useful, but i no longer scoff at it "because i can program." Even the decision to mock something out in keynote or qc or whatever is fraught with the decision that you've committed to an aesthetic, to some animation settings, to your app chrome, etc. sometimes those things don't exist and you're trying to debate things way more elemental. in those cases, paper prototyping can save you lots of time.
but again, if you've already decided something is a good idea, then in-app or live prototypes are incredibly valuable for being able to 'tweak the knobs' and 'live with your mistakes' while you find easing curves or animation timings or whatever. if you're flying blind, then you could do a whole lot worse than paper-larping for a few minutes while you decide what your mobile strategy is.
which is to say, if you're at the stage where you're going "head to head with your competitors" then you probably should be doing real prototypes or building real mvcs in whatever system works best. this is effectively the same as what they're saying in the original article: you can't only paper prototype and expect it all to be peaches and cream.
even as i'm writing this i'm getting a huge fred brooks flashback here because the reality is that making good ui is actually quite time consuming even if you have fancy whizbang frameworks. this is why people love framer or qc—they simplify thinking about interaction to the most basic aesthetic choices as relates to some states: this thing fades out while this thing flies in. or these things pop in at staggered delays when you go to the next part of the tutorial.
i'm not trying to knock those tools, but the truly hard ui problems are rarely solved by a single motion sketch in any app. and honestly, even those keynote/qc/framer 'high fidelity mocks' are, to my mind, as disingenuous as polished paper prototypes because most of the time their animations are wildly disconnected from the reality of using the app day to day when you're trying to accomplish anything.
the reality mirrors something closer to the epic 500+ email process thread from the creators of Threes, a thread so epic that it doesn't deserve to be occluded within an html link, i'll just put it here
http://asherv.com/threes/threemails/
i guess really what i'm saying is that all these things take time and the 'real world' process is long, but that if you're lucky, you get better at spotting which things your can gut check with paper and which things you need to bite the bullet to just see at least once. and then you just iterate until things get better, i guess that's the atwood strategy.
there's a sort of stupid bravado here in the valley where people like to eschew 'trying something dumb' for 'making an mvp' and sometimes it's a good forcing function to get out of a funk but often i see it results in lots of wasted time and pointless code that goes nowhere. maybe i'm getting old or something, though.
obligatory line about it taking a tough man to make a tender chicken