Зачем в Go амперсанд и звёздочка (& и *)?

Ошибка. Символ каретки в Паскале так же используется, как и звездочка в сях, в зависимости от позиции — перед переменной/перед типом для разыменовывания или задания типа. В Паскале каретка до — тип, после — разыменовывание:
PMyType = ^TMyType - указатель на TMyType
var
abc: PMyType;
...
:= abc^.field;

Паскале — нет, мнемоники никакой нет.

Почему нет? Вроде, есть. Не везде допустима, но есть.

var
abc: ^Integer;
...
abc^ := 123;

Эта логика начинает резко хромать, когда определения усложняются:

typedef int (*fun)(void*);

тут уже надо вводить курсы чтения таких конструкций с размоткой внутрь структуры определения, молодёжь не понимает, да и аксакалы иногда спотыкаются на особо сложных заворотах.

А вот такое компиляторы уже не осиливают, выдавая ошибки:

typedef int (*fun1)(int) (*fun2)(int);

хотя, казалось бы, чего сложно — определить fun2 как указатель на функцию с int параметром и указателем на функцию int->int в результате…
ан нет, случился зашкал сложности, и без промежуточных typedefʼов не выкрутиться.

Стиль таких определений в Pascal, Go (*) и многих других — читаемее и не страдает такими ограничениями. Цена же за это — что надо, например, явно писать слова var — для переменных, func — для определений функций. Как по мне, цена вполне разумная, польза перевешивает.

(*) Хоть я его и громко ругаю за кучу прочего.

Вырожденный пример будет какой-то такой

// Note: both FirstError and SecondError implement 'error' interface
// and use some data from value when their respective Error() is called

// May return non-nil error, if code fails
func first(arg MyData) *FirstError { /* some code here */ }
// May also return non-nil error, if code fails
func second(arg MyData) *SecondError { /* some other code here */ }

func third(arg MyHugeData) error {
    if err := first(arg.DataField); err != nil {
        return err
    }
    return second(arg.DataField)
}

func fourth(arg MyHugeData) {
    if err := third(arg); err != nil {
        fmt.Println(err.Error())
    }
}

Такой код КМК вполне может случиться — "просто верни статус последней операции дальше по стеку". Во-первых, результат всегда будет трактоваться как неуспех. Во-вторых, при попытке узнать причину мы получим nil-pointer panic из по сути ниоткуда. Пример с обработкой ошибок КМК просто будет самый типичный. Я в своё время нарвался на такое поведение в другом контексте, подробностей уже не помню.
Но суть была именно такой:

1. Есть несколько типов, приводимых к одному интерфейсу.
2. Каждый из типов требует не-нулевой инстанс чтобы корректно реализовывать указанный интерфейс
3. В некоем коде, допустим при передаче через канал, указатель на объект какого-либо из конкретных типов приводится к интерфейсу. При этом для канала nil pointer является абсолютно корректным положением вещей и обрабатывается на принимающей стороне как положено.
4. На принимающей стороне не-нулевой указатель на интерфейс неожиданно оказывается очень даже нулевым, т.к. сам по себе vtable бесполезен. Результат — NPE где не ждали.