For really simplistic applications, omitting SQL is a fine choice, especially in golang you don't have the comfort of a well established ORM.

There exists libraries that do provide an ORM, but since the declarative side of golang is limited compared to languages, say Python, I find them unwieldy. Also, the current trend shuns the usage of an ORM in golang and encourages directly or indirectly writing SQL queries and interacting with the database through database/sql and its extending libraries, like jmoiron/sqlx.

For really simple application omitting a k/v store is even better. Why isn't a simple map good enough?

Lack of persistence is one such reason. Because Go's built-in maps are not completely safe to use concurrently, too, their usefulness as a key/value store is somewhat limited in many applications.

Naturally, it's possible to build a solution to persist Go maps and to make them safe to access across goroutines, but by that point you've built a persistent key/value store.

Depends on the requirements (persistency, concurrency etc.) No offense, but it's bit pointless to discuss it further without deeper context.