Yes. I use rectangular cut and paste from time to time. My problem with emacs:
... lots of files in the output of ldd
To begin with, half the list is display related stuff: All the things that start with libX are for GUI use, and I think a few others too. I don't use the X-windows version, and my executable is only 8.5 MB large (ls -lL `which emacs` -> 8501132). Is using a GUI "bloat"? That's in the eye of the beholder.
And: One man's bloat is another man's functionality. For every library that emacs uses, there is a good reason, namely some functionality of emacs that needs that library. For example, on my machine emacs is linked against libz ... that's because it can edit (read and write) compressed files directly. Some person found this to be convenient functionality.
And the size of the executable and the shared library make little difference. Programs being executed are demand paged, and shared libraries are loaded only on demand and shared among all processes (thence the name). So the size of the executable and the number of shared libraries matters little to performance.
Every time a new version appears, I must struggle with the configuration files in order that
it continue behaving as I know it since decades.
There are two questions mixed together here. First one is startup files (the .emacs file in one's home directory, and all the files in .emacs.d that are loaded). It is indeed a problem that some OS distributions like to dump a huge amount of stuff in there; that's typically worse on Linux, in particular on distributions that have been customized for corporate in-house use. All these are things that some people find helpful, but loading them at startup slows emacs down significantly (I even notice that on large, cloud-based machines where I do much of my editing). The fix is simple: Go into those places, and delete unnecessary files, and remove unnecessary lines.
The second question is that emacs seems to be seeing active development, so changes and new functionality will show up. If you don't like that, you'll have to compile your own version from frozen source code.
And I used it in machines with few ram. I suspect, this is bloat. Is it not?
I run current emacs versions on a Raspberry Pi 0 (with 1/2 GiB of RAM) no problem at all. My main home server has only 3GiB of RAM, and I can do development on it without any problems. For today's environment, those are low-memory machines. I've run emacs since the late 80s, on all manners of small machines. For example, in the early 90s my desktop machine was a NeXT, which had 8 MiB of RAM, and my home machine a 386-40 running Linux on 4 MiB. I used emacs all the time, with no problems. Obviously, these machines had all manner of other problems; for example running X on a 4MiB machine without FPU was painfully slow, and the NeXT's OS had more bugs that a dog has fleas, so I eventually replaced it with a VT220 connected via serial line to a RS/6000, but lack of memory for running emacs was not an issue.