Clunky? Yes (adorably so for us Emacs lovers, but I understand this can be problematic for new users). But slow? That doesn't sound like Emacs, it's probably some misbehaving third party package included in Spacemacs that made it feel slow.
Also, it doesn't seem quite fair to blame Emacs for inscrutable interaction between third party packages, rather than blaming the packages involved in the interaction.
If you do ever try Emacs again, hold off on using third party packages. The bar for getting a package admitted into Emacs is higher than just putting it up on GitHub, so naturally the built-in packages tend to be more robust on average (which is not to say there aren't many excellent third party packages, there are!, but it's reasonable to be more weary of them than of built-ins).
Also, could you say a bit more about how you found the Emacs documentation puzzling? I love the documentation, it's thorough and very readily accesible. I don't use IDEs (because I have no use for them) but if their documentation is even better than Emacs's I might play with one just to enjoy the documentation.
(Finally, if you meant Spacemacs's documentation ignore the previous paragraph: I have no idea what its documentation is like, I was only talking about Emacs.)
re: The documentation, I found the standard Emacs docs good enough to learn high-level Emacs concepts and such, but whenever I went searching for the nuts and bolts of how to configure specific bits of functionality, the documentation I stumbled upon (it's rarely easy to discover) either a) assumed a high level of proficiency and understanding of Emacs internals, often accompanied by (or consisting entirely of) large snippets of Emacs LISP b) was written in a kind of reference style that failed to give much context or help the user along in any way, or c) would be contradicted or superseded by some other piece of documentation, usually because of subtle package incompatibilities (probably exacerbated by Spacemacs in my case).
The Emacs community does not seem to have converged on a particular documentation idiom so there is a wide range of documentation quality for various configuration use cases. Most of the time I ended up finding bits and pieces of answers on Stack Overflow or other message boards, and proceeding with a lot of trial and error. That is fun sometimes, but not all the time; it was a rare experience when the documentation really nailed it for me. There does not seem to be much thought to the user experience on the whole.
Emacs OOTB sucks and some of the most useful packages will never be built-in, because developers don't want to deal with license assignment and locking themselves to the slow release cycle of Emacs. Also the community can be discouraging.
"Emacs OOTB sucks" People say that, and those people are entitled to their opinion. (A word of warning: I think many people who say that are not actual Emacs users.) I'll keep happily using vanilla Emacs while people complain about it, though.
Of course, I don't really use it OOTB, I mean, I do have a configuration. My 700 line init file installs some 20 third party packages from MELPA, and changes a lot of defaults. I've also written about 1200 more lines of Emacs Lisp distributed among some 25 tiny packages I use. But I did start with Emacs OOTB and never thought it sucked, I thought instead, over and over, that some minor aspect could do with some tweaking. :P
And not locking yourself to Emacs's slow release cycle is a perfectly valid reason for not wanting your packge to be built-in. I don't think there is anything wrong with the fact that many excellent third party packages will never be built-in.
Well, you're right, it's not so vanilla anymore. :)
But that has accumulated over the course of about 10 years, so its really not a lot. And the possibility of having everything just the way I like is what drew me to Emacs in the first place! A shorter config would be an indication that either (1) I happened to like everything exactly the way it was by default, or (2) annoyances can't actually be fixed. I don't think any software could fall into (1) (right?, there's always something you wish were slightly different, or something you want to automate) and Emacs, unlike most programs, does not fall into (2).
Also if you saw my configuration and compared it people who use Doom or Spacemacs, or even just Helm or Ivy, you'd think my Emacs is very vanilla.
Also, it doesn't seem quite fair to blame Emacs for inscrutable interaction between third party packages, rather than blaming the packages involved in the interaction.
If you do ever try Emacs again, hold off on using third party packages. The bar for getting a package admitted into Emacs is higher than just putting it up on GitHub, so naturally the built-in packages tend to be more robust on average (which is not to say there aren't many excellent third party packages, there are!, but it's reasonable to be more weary of them than of built-ins).
Also, could you say a bit more about how you found the Emacs documentation puzzling? I love the documentation, it's thorough and very readily accesible. I don't use IDEs (because I have no use for them) but if their documentation is even better than Emacs's I might play with one just to enjoy the documentation.
(Finally, if you meant Spacemacs's documentation ignore the previous paragraph: I have no idea what its documentation is like, I was only talking about Emacs.)