That depends entirely on the implementation. Almost every respectable implementation strategy is going to have better performance characteristics than an interface{} though.
Not exact in all cases, but in some and very close in most others. And it isn't "magic pixie dust"--it is a lot of hard work to implement generics in a way that is both ergonomic for the programmer and efficient.
It depends. There is always an increased demand for memory (which can impact the whole hierarchy) but other than that it shouldn't be bad. And I think the point is that compared to interface{}, generics will almost always win. And realistically, compared to hand-rolled, you'd need to hand-roll (or codegen, whatever) multiple implementations which, as machine code, would end up exactly the same as the generic implementation.
And what are we optimizing for anyway? Reading a bunch of code that uses an off-the-shelf library's Stack or Tree or whatever is always going to be easier to read than having to also have to inspect the three hand-rolled Tree implementations, two of which are probably buggy, in addition to the actual client code trying to use the tree to do real work. Or a library that implemented it using interface{} which is a big middle finger to the whole type system, completely discarding the compiler's ability to detect otherwise trivial mistakes.
Of course they could just use interface{}... But by doing that they lose both type safety and performance.