Encoding.GetBytes() gets encoded bytes for an input char sequence.  Note that Encoding.GetBytes() is different than Encoder.GetBytes() because Encoding expects discrete conversions while Encoder is designed for multiple conversions on a single input stream.

If you have a bunch of input characters to encode to a code page, and process those chars with multiple calls, then there is a potential that some state must be maintained between calls.  Some examples of state are:

• For example, ISO-2022-xx code pages can emit "shift" sequences that change between ASCII and double byte modes.  Encoding shifts back to ASCII at the end of each call so that applications can rely on a known state.  An Encoder can persist the state so that the stream can continue without the wasted switching back & forth.  Unnecessary switching could also introduce security problems or make string comparisons more difficult.
• Any char sequence that includes surrogate pairs could end with a high surrogate.  The Encoder will remember that high surrogate so that it can be combined with a low surrogate at the the beginning of a following call.  Encoding won't be able to maintain the state, so the character will be sent to the EncoderFallback (ie: turn into a ? or cause an exception)

Of the Encoding.GetBytes() overloads, which one is best?  It depends on the situation.

If your input is strings, then you may want to use the string overload.  The version that returns a byte[] needs to check the length first and allocate a buffer, but for many purposes that may be acceptable.

The char* version can allow some fast techniques, particularly with multiple calls (using the Encoder) or inserting into existing buffers, but it is unsafe since it requires pointers.

If you're converting lots of stuff, then it might be wise to reuse the same output buffer, so the overload that accepts an output byte[] may be best.

You should also look at the Encoder.Convert() methods.  Convert() converts as much data as possible, and will not throw an exception if the output buffer is too small.  For continuous encoding of a stream this is often the best technique.