Extensible means that you can go beyond simple customization and create entirely new commands. New commands are simply programs written in the Lisp language, which are run by Emacs’s own Lisp interpreter. Existing commands can even be redefined in the middle of an editing session, without having to restart Emacs. Most of the editing commands in Emacs are written in Lisp; the few exceptions could have been written in Lisp but use C instead for efficiency. — GNU Emacs manual, Introduction
Org can be used as a TODO lists manager and as a planner. Org is a great plain-text table editor. Org is an authoring and publication tool. Org makes literate programming a handy and natural way to deal with code. — Org mode feature list
Perhaps the most relevant link for malleability is the original 1981 paper on TECO Emacs, written before I was born, but describes many qualities I recognize in the ELisp Emacs I grew up on.
Emacs “happens” to be FOSS , but the paper stresses how the system & language were designed to allow users to mold it at run time without the barrier of forking & recompiling from source, and how bottom-up empowering users led to better features than “careful design” could have achieved.
Selected points I found notable [my own interpretations bracketed]:
Editing Language is tweakable (again at run time) by re-binding keys to macros / existing commands / custom commands. This gives agency to users with less programming skill!
Language separation being necessary so that tweaking Editing Language can’t break Programming code.
Key bindings are shallow “keyboard sugar” over the concepts of Programming Language. Commands are (almost) regular functions. User can invoke any command by name, bypassing the sugar.
Support Buffer-local & mode-local bindings.
Commands (and generally as much of the system as possible) implemented in Programming Language which was chosen to be interpreted not compiled, so that users can redefine at run-time and experiment.
“The only way to implement an extensible system using an unsuitable language, is to write an interpreter for a suitable language and then use that one”
“variable [and function] names are retained at run time; they are not lost in compilation”
reflection facilities enabling things like “The error handler for debugging program errors is an interpreted program itself … Users have actually written … complete replacements”
Commands are extensively parametrized by variables. User can achieve quite a lot by simply setting [global] variables.
Dynamic not lexical scoping deliberately choosen to make code less encapsulated and more customizable by other people.
Original code written as if var is global, but it can pay off for local parametrization.
Unique concept of file/buffer-local variable scopes! Very common for modes e.g. comment start var must vary between programming languages. Again, if programmer went to the trouble of parametrizing code, maximize the payoff.
Commands and especially compiled code extensively parameterized by calling “Hooks” at interesting points.
“These hooks can be thought of as compensating for the fact that some parts of the system are written in assembler language and cannot simply be redefined by the user.” [I found this especially thoughtful ]
Social dynamics like “library system” for loading extensions written by others…
[Well, later Emacs actually lagged behind for decades in ease of obtaining 3rd-party libraries. “too cathedral, not enough bazaar…” Much better now with MELPA, still not as smooth as say VSCode extensions. But I feel a trade-off — VSCode extensions are more encapsulated making install smoother but also more “opaque” and harder to inspect/hack.]
, but the paper stresses how the system & language were designed to allow users to mold it at run time without the barrier of forking & recompiling from source, and how bottom-up empowering users led to better features 
]