A fiber is not the same thing as a stackful coroutine. That makes their claim that "Stackful coroutines are up to 93% slower than stackless coroutines on Windows" grossly misleading.
A stackful coroutine is a concept. A fiber is usually a concrete implementation of a light-weight thread. A fiber typically includes machinery and interfaces for general purpose scheduling. That machinery can be quite heavy weight--such as calling into the kernel to change a signal mask--and is above and beyond what either a stackful or stackless coroutine needs.
Like a stackless coroutine, a stackful coroutine could be implemented with just a single jump. How you end up implementing these concepts depends on your ABI, language semantics, and myriad other considerations. C++ chose stackless coroutines because of its peculiar restrictions--need for backwards compatibility with native OS ABIs, and in particular inability to change how "the stack" is normally managed.
But at least people are beginning to appreciate how coroutines (of any variety) are powerful concepts that can not only simplify code but make it easier to optimize code.
Other than this paper, http://www.inf.puc-rio.br/~roberto/docs/corosblp.pdf, which revived interest in coroutines, I don't have links handy for authoritative sources in the academic literature regarding nomenclature. "Stackful" and "stackless" are relatively recent descriptions and not too long ago they could have meant the complete opposite--Stackless Python (http://www.stackless.com/spcpaper.htm) implements what would now be called stackful coroutines.[1] But I think it's fair to say that today there's a relatively fixed nomenclature about the concepts. But people still create unnecessary confusion by conflating implementation details (often coincidental or accidental) with the abstract concepts.
[1] The Stackless Python website talks about microthreads and tasklets, but the original paper begins the discussion with continuations, generators, and coroutines, and builds up from there.