readline is implemented alongside bash by the same author and used by bash and among popular shells, mostly only bash.
The readline library was spawned off bash. bash 1.02's ChangeLog file has:
Wed Jun 28 16:51:42 1989 Brian Fox (bfox at aurel)
* New directory: LIB contains readline and history stuff,
and is Make-able on its own. Also contains its own
ChangeLog
* history.c: removed shell dependent stuff, made into standalone
library.
Tue Jun 27 13:05:54 1989 Brian Fox (bfox at aurel)
* readline.c: removed shell dependent stuff.
* New file: bashline.c contains all of the shell specific
readline material in an attempt to begin using the
readline stuff as a library.
Mon Jun 26 13:35:16 1989 Brian Fox (bfox at aurel)
[...]
* readline.c, jobs.c
Make commands that do not complete sucessfully restore the
tty state to whatever it was before the command was executed.
zsh used a modified version of bash's readline in it first 1.0 version in 1990 as its own line editor was not ready yet, but switched to its own in 2.0 four months later in 1991. From the README file in 1.0:
This is version v1.0 of zsh. I incorporated the GNU "readline"
editor, written by Brian Fox, into the shell, just to make my life
temporarily easier. I made lots of changes to it, so if there are any
bugs in the editor, they're probably my fault. readline will not be a
part of the next version of zsh.
Ash-based shells typically use BSD's libedit (in the case of dash it's often not enabled at compile time as dash is only intended for running scripts, not as an interactive shell).
The clone of the Unix V10 / Plan9 rc shell by Byron Rakitzis gives you a choice of line editors at compile time: GNU readline, Simmule Turner's editline and Gert-Jan Vons's vrl. The first version only offered readline. es and akanga, based on rc offer a choice of readline vs editline.
busybox has its own line editor which is used by its hush and ash based shells as well as other applets such as its bc, ed, fdisk.
readline is great in that it provides a line editor that can be (and is) used in many different tools, providing consistency but, though it's probably one of the most if not the most feature-rich general purpose line editing libraries, it is relatively limited in what you can do with it. It's also licensed under the GPL, so can only be used in software licensed under the GPL or compatible.
Most shells including ksh, pdksh and derivatives, tcsh, zsh, fish or yash have their own line-editor, often more advanced. The line editors of ksh were written circa 1983 long before bash, and that's the interface that bash's readline mostly copied. pdksh and tcsh line editors also predate bash and readline. A vi-style line editor is specified by POSIX, based on ksh's. The emacs one is not specified by POSIX as Richard Stallman (the main author of GNU emacs and incidentally also came up with the "POSIX" name) objected to it¹.
Note that there are good reasons why you would want to enable the bracketed paste mode in terminal editors or line editors that support it. See: How can I protect myself from this kind of clipboard abuse?.
¹ See "In early proposals, the KornShell-derived emacs mode of command line editing was included, even though the emacs editor itself was not. The community of emacs proponents was adamant that the full emacs editor not be standardized because they were concerned that an attempt to standardize this very powerful environment would encourage vendors to ship strictly conforming versions lacking the extensibility required by the community. The author of the original emacs program also expressed his desire to omit the program. Furthermore, there were a number of historical systems that did not include emacs, or included it without supporting it, but there were very few that did not include and support vi. The shell emacs command line editing mode was finally omitted because it became apparent that the KornShell version and the editor being distributed with the GNU system had diverged in some respects. The author of emacs requested that the POSIX emacs mode either be deleted or have a significant number of unspecified conditions. Although the KornShell author agreed to consider changes to bring the shell into alignment, the standard developers decided to defer specification at that time. At the time, it was assumed that convergence on an acceptable definition would occur for a subsequent draft, but that has not happened, and there appears to be no impetus to do so. In any case, implementations are free to offer additional command line editing modes based on the exact models of editors their users are most comfortable with." in the RATIONALE section of the POSIX sh specification.
