None of those things are really roadblocks to Getting Shit Done though, except maybe dynamic loading.
Go has plenty of support for global constant values that take the place of enumerations, even to the point of having an "iota" syntax to make initializing constants easier.
Exceptions are generally an anti-pattern in my opinion: a hack to get around the ability to return multiple values from a function, so that error conditions can be handled in-band. The other technical challenge exceptions sometimes provide -- guaranteed cleanup after code that might fail to execute -- can be handled by Go's deferred function execution.
Generics are a powerful abstraction, but Go has very good support for (un)boxed values and interfaces, so the only thing you would get from generics is a bit more type safety. The additional complexity required to support generics isn't worth it.
Dynamic loading is arguably a blocker for certain modes of development and distribution, but by not supporting dynamic loading, Go can make tremendous simplifications in its module system. Making the assumption that every go library is distributed in source form greatly reduces compatibility friction and runtime bugs. "DLL Hell" may be a "solved" problem on most systems nowadays, but there are a lot of moving parts to enable that.
The simplifications that Go makes are 100% worth it in my opinion. There is one place where Go sacrifices something that can't be replaced is that a stop-the-world garbage collector may be unacceptable for some applications. Other than that, codebases aren't actually served by having too much power in their languages, even if an individual programmer might be.