А если бы там возвращалось time.Time, а не структура,  вы бы тоже указатель сделали?

+ зачем вы каждый раз аллоцируете под errors.InternalError{} и errors.NoteNotFound{}?

Я бы в обоих случаях возвращал {значение, ошибка}
Только в случае со структурами должен быть указатель

Как, собственно, повсеместно и делают

Ну вот time.Time - это структура. Вы бы возвращали указатель на нее?

Сложно представить такой кейс

А если бы int был, вы бы возвращали указатель?

Я вам ответил про это :)

Разговор уже ни о чем. Все сказано

Вы никак не аргументировали почему у структуры всегда должен быть указатель. Я вам привел пример из стандартной библиотеки, где time.Time является структурой и не возвращается по указателю, а имеет метод IsZero()

и какой смысл в result = NotesUpdateResponse{} ?

к слову о вашем споре: есть какая-нибудь литература по теме указателей, когда стоит применять, когда нет?

чтобы однозначно сказать

Однозначного ответа нет, но на тему указателей хорошо расписано на ardanlabs.com
Использовать указатели стоит однозначно тогда, когда у вас есть методы, принимающие указатели и изменяющие данные, которые лежат по этим указателям.

type Cache struct {
sync.Mutex
Entries map[string]Entry
}

ну и дальше Get/Set без поинтеров никак

Не знаю, разве другой вариант?

Сейчас подумал о iota. Можно ли как-то с этим. В общем, посоветуйте

Использование везде указателей ухудшает читаемость кода, потому что становится непонятно меняет ли что-то в объекте по этому указателю метод, куда этот объект передается. Если бы передавалось по значению, то точно объект оставался бы не тронутым.
С другой стороны копирование по стеку туда-сюда возможно менее эффективно, чем размещение объекта в куче. А возможно и более - это зависит от каждого конкретного случая.
Я лично ратую за читаемость.

Для наглядности. Предлагаете сразу возвращать без переменной?

как минимум

А еще как?