Moreover, modern CS education teaches a lot of things that weren't taught in the past, and it likely only gives a hand-wave to things like memory-management etiquette in low-level C (or Go) API design. This is likely because (1) it's not that difficult to read up on the specifics if you're otherwise a competent engineer and (2) other concepts were valued higher. Perhaps the course focused on writing code with borrow-checking in mind instead.

For the most part, it was the other way around, we mostly learned abstraction, so the lessons in class focused on how to encapsulate and hide state. At a higher level than that, education really focused (and still does, I think) on engineering for functionality over engineering for performance.

In some sense, the problem with APIs that allocate is larger now than it ever was before, and growing larger. Data sizes are bigger now, and memory pressure relative to what the processor can do is going up.

At the application layer, I really don't care to utilize a partially filled buffer, I want a result set that has what was read. Of course, nobody is being stopped from creating such things as abstractions. StreamReader for C# as an example.