On the API topic, my read is that the post cautions against writing too many wrappers around standard ML libraries. My experience is that folks tend to write wrappers too soon, and then they can make coding harder in the future. My rule of thumb is to not write a wrapper until you have 3 distinct production implementations of something, so that you have real information on the appropriate level of abstraction needed.

On the other topics, it depends also on your stage of startup. If you're pre-product-market-fit, you're faced with the dilemma between spending time for the long term (if your company survives) and iterating faster to ensure that your company survives. So it's a balancing act depending on your level of confidence in profitability, next round of investment, etc.

Early on, I'd expect 80% or more of research experiments to fail and be thrown away. In those cases it's mainly important to share the findings of your research with the rest of the company. Writing is ideal but tech talks work too.

For the projects that make a difference to the company, it's important to identify when they've met the bar and then dedicate some time to making the project easier to maintain and extend (whether improving the code or docs).