1) When learning a new language, it's typically a good idea to do a project you already know how to do in another language, so that you don't have to learn both what to do, and how to do it, at the same time.

2) WebSockets and socket.io, and all other web/TCP based networking (HTTP2 streaming etc) are all pretty bad for real-time games. If you want real-time, then you want UDP, which means you either don't use a web browser, or you hack something crazy on top of WebRTC, which in itself is a big undertaking in any language.

3) Golang can call into "foreign functions" written in C, and Lua is written in C, so it's totally possible. Whether you'd get to the point where your game is good enough that other people would write scripts for it is another question. Also beware: Lua is not thread safe. There are other external scripting options, including forking a sub-process that you talk to using pipes, or starting a separate script interpreter over a network interface, or using shared memory for communication, so don't think that you HAVE to embed a scripting language, or choose only one language. It all depends on what your particular needs are.

4) That sounds entirely like a world design and implementation / algorithm question, not a language specific question. Every game has to make some trade-offs between costs (hardware resources, implementation time, skill of people involved) and features/polish. Companies like Blizzard do what they do so well because they can basically pick and choose between many of the best game programmers in the world, and they have very large budgets. Small indie games don't have that option, and are often built by people earlier in their career, who are not as experienced in where things can go wrong and how to avoid it.

Good luck on your project!

If you have to be on the web, then websockets are the least bad option, IMO.

Databases should not be involved in the game loop. You can use a database to load data for a particular player when the player logs in, and to checkpoint data to every once in a while. Preferably, you'd do the actual database I/O in some other thread, or asynchronously, so you don't block the main game thread with lots of slow operations. (In fact, all I/O should be asynchronous and/or on a separate thread.)

I'd suggest, instead of saying "Z axis" for multiple maps, just call them "multiple maps." They may have different map IDs. When moving from one map to another, place a portal that internally has the information "this portal takes you to position X, Y on new map ID I."

If you don't support instancing; all players on a map can see each other; then most robust is to build one process per map. When travelling, the client connects to some other process (on some other IP address or port, perhaps.) Alternatively, use a front-end proxy which sends the player to the correct map process based on where they're at (based on a cookie, or some connection parameter, or whatnot, depending on your implementation.)

Once you have a process that runs all entities within a given map, the structure of that is no different from any other game. Either you do the object mess and "tick" each "entity object" to figure out what it should do, or you make objects compose a number of sub-behaviors, and let each "behavior manager" iterate over its own "domain of objects" every so often to evolve the data. The benefit of the former is that it keeps behavior in each object. The benefit of the later is that it caches better and generally performs better.

Key is to not re-do work more than once. For example, if you have subsystems like path finding and attack logic and magic effects and physics, that all want to know "what things are within X tiles of me," then  you want to start your iteration by finding things within X distance of each entity, and re-use that discovered state across each of those subsystems for that turn/tick/iteration. Similarly, path finding between larger chunks of tiles can be done once, and stored as a graph; path finding for an individual object then just becomes "find the exit of the current chunk" and follow the canned path from then on. (Until you're inside the same chunk as the target destination.)

When loading the map, should I create AND "cache" (keep on memory server, not in the DB) every single tile as an object?

You should absolutely keep your entire level in memory, not in the database, yes.

Whether that's "as an object" or "as an array of structs" or "as five different arrays, each keeping a separate property about the tile in question" is entirely up to you. I listed them in order of most convenient to least convenient, but also slowest to fastest.

class Tile {
  TileType *type;
  int woodResources;
  int oreResources;
  int waterLevel;
  int fireAmount;
};
	Tile **theMap = new Tile*[100*100];
for (int y = 0; y != 100; ++y) {
  for (int x = 0; x != 100; ++x) {
    theMap[y*100+x] = new Tile();
  }
}
	

struct Tile {
  TileType *type;
  int woodResources;
  int oreResources;
  int waterLevel;
  int fireAmount;
};
Tile **theMap = new Tile[100 * 100];
for (int y = 0; y != 100; ++y) {
  for (int x = 0; x != 100; ++x) {
    init_tile(&theMap[y*100+x]);
  }
}
	

TileType **theMapTileType = new TileType *[100*100];
int **theMapWoodResources = new int[100*100];
int **theMapOreResources = new int[100*100];
int **theMapWaterLevel = new int[100*100];
int **theMapFireAmount = new int[100*100];
for (int y = 0; y != 100; ++y) {
  for (int x = 0; x != 100; ++x) {
    init_tile_yx(y, x);
  }
}