"What would such a change accomplish?"

I can answer this for myself at least:

TL;DR it allowed me to scale sqlite query complexity significantly which increased sqlite's utility and applicability to new problems.

I have long used a pre-processor mechanism I wrote/re-wrote to make my sqlite3 life easier.  I am generally using sqlite3 embedded into other applications which generate sqlite queries via C/C++ or other language programmatically (usually based on a pattern query who's components are chosen/replaced at run-time).  

Often with large stand-alone DBs (1-100GB+) so indexing and query structure is critical for performance and run-time memory foot-print control.  Often times overcoming the limitations of sqlite's query optimizer required peculiar query structures (trading deep joins for complex sub-selects for example, or collapsing a macro argument to a value outside the query to prevent re-execution of a sub-select billions of times).

It's been a lex/yacc, flex/bison and now flex/lemon text pre-processor integrated into shell.c as well as wrapped around sqlite3_prepare_v2() in my applications.  

The basic outline of syntax is:
set name(arg,list) = *; -- (args) may be present or not, used or not by the definition.
clear name; -- delete the variable/macro in a shell session | .spclear for all

It operates similarly to CPP in that it can be a coherent expression/function or it can be a brute-force text/fragment replacement.

(oversimplified examples):
set a=42; -- simple readability variable
select foo from bar where condition=a;

set transform(a,b,c) =(cast=(a as int) + cast(b as int) - cast(c as int));
select transform(1,2,3) as t from foo;

Where this gets very useful is when queries get quite complex:
- multi-way joins with NULL tolerance/manipulation
- extensive casting/error checking (case statements)
- complex sub-selects that make the query otherwise unreadable
- case statements generally make complex queries unreadable just from the sheer depth of context one must track as you read - vs the hierarchical nature of a macro instance

ex:
set complex_decision1(a,b) = (select foo from p join q on a in(select ...;
(replace ... with complexity of your choice)

select
     ... -- elide for brevity
where 
     complex_decision1(var1,var2) -- macro based choice based on whatever
     AND
     complex_decision2(var3)

In short, this capability allowed me to scale up sqlite query complexity radically while still being able to read either other human code or programmatically generated readable query code using this macro idiom.

I added a shell flag to show the expanded query in final expanded form for debug.  I preserved formatting and comments to maximize the chances the error print would show the error in the context of the abstract/pre-expansion code to help you find it.

I realize and have experienced the many errors one can introduce via this mechanism, but they were an easy trade-off to trying to read/write queries who's "select" arguments alone could be a 1000's of characters one all casting and sub-selects were factored in.

Whether or not the macros persist in the shell or are stored in the DB itself was never a concern for me as I was embedding sqlite in other applications.

I also realize there are 1/2 dozen other ways to do this... this one has repeatedly offered me the most maintainable and rapid solution.  So, having a similarly concise way to manipulate variables/macros would be a very welcome addition to sqlite for me.

- nesting - yes... there's an arbitrary 100 limit on recursion depth through the token expansion process to prevent run-away... it could/should be more elegant than that, but.

- textual? - yes, token based using flex/lemon to very crudely sort out tokens without getting mired in full SQL syntax parsing (for risk of fouling up the main keyword commands (select, insert, create, etc...).  The right-hand-side of the token can be an arbitrary code fragment.  The only restriction at the moment is that it can't have mis-matching parens owing to the basic lemon expression rule of expr ::= LP expr RP. being core to it's pattern matching in my .y file.

- why use a syntax that is ambiguous with SQL? Mostly expediency... were I trying to generalize this to inclusion with sqlite, I might re-think that as sqlite's namespace generally is pretty ambiguous already, but the extra characters are extra... not needed to get the job done - 99.9%.  cpp was my mental model and it relies on you to sort that out on your own.

It _could_ either have marker characters or do a better job checking for circular references/ambiguity.

set ab(n) = (select a + b from f where rowid=n);
set aa(n) = (select a + a from f where rowid=n);
set bb(n) = (select b + b from f where rowid=n);
set sm(a,b)=(select sum(aa(a))+sum(bb(b)) from f);

INPUT:
select
     ab(3) as a,
     ab(2) as b,
     aa(7) as c,
     bb(5) as d,
     sm(2,3)   as s
;

OUTPUT (with .spexpand shell flag set to "on" to show expanded prior to query)
-- set ab(n) = (select a + b from f where rowid=n);
-- set aa(n) = (select a + a from f where rowid=n);
-- set bb(n) = (select b + b from f where rowid=n);
-- set sm(a,b)=(select sum(aa(a))+sum(bb(b)) from f);
select
     (select a + b from f where rowid=3) as a,
     (select a + b from f where rowid=2) as b,
     (select a + a from f where rowid=7) as c,
     (select b + b from f where rowid=5) as d,
     (select sum((select 2 + 2 from f where rowid=2))+sum((select 3 + 3 from f where rowid=3)) from f)   as s
;
a   b  c   d   s 
--  -  --  --  --
11  7  26  20  70


INPUT (silly example - but to your "textual?" question:
set fromclause=
from f
where
   b > a
;
select rowid fromclause();

OUTPUT:
1
2
3
4
5
6
7

"(select sum((select 2 + 2 from f where rowid=2))+sum((select 3 + 3 from f where rowid=3)) from f)   as s"

Showing the dangers of ambiguity... note "a" and "b" are both column names and macro variable names.  Big boy rules apply in my example to avoid this.  I often use _NAME or some such to avoid this... but this was a quick mockup.

MACRO MONEY(colname)  = "printf('%.2f',"       + colname + "*.01)"
MACRO DATE8(colname)  = "strftime('%m-%d-',"   + colname+ ") || substr(strftime('%Y',"+colname+"),3,2)"
MACRO DATE10(colname) = "strftime('%m-%d-%Y', "+ colname+")"

FUNCTION PBMAIN 'written in PowerBASIC  sql statement pre-processor

 slOpen ":memory:"
 slexe  "create table t1(c1 integer,c2)"
 slexe  "insert into t1 values('123','2022-11-25')
 sql =  "MONEY(c1),DATE8(c2)"
 GetRs  sql

 '1.23   11-25-22

END FUNCTION

SUB GetRS(sql AS STRING)
 DIM sMacro(1 TO 3) AS STRING
 sMacro(1) = $MONEY                                     
 sMacro(2) = $DATE8                                     
 sMacro(3) = $DATE10                                    
 For x = 1 TO 3                                         'for 
  sMacro=sMacro(x)                                       'macro name found in sql
  Do                                                    ' do
   startword = INSTR(sql,sMacro)                        '  Start position
   IF startword = 0 THEN EXIT DO                        '  not found, exit do
   endword = INSTR(startword,sql,")")                   '  end position
   sFunc = MID$(sql,startword,endword-startword+1)      '  sFunc = macro name
   sCol = LEFT$(MID$(sFunc,LEN(sMacro)+1),-1)           '  sCol =  colname
   SELECT CASE sMacro                                   '
    CASE $MONEY :REPLACE sFunc WITH  MONEY(sCol) IN sql '  replace with money(colname)
    CASE $DATE8 :REPLACE sFunc WITH  DATE8(sCol) IN sql '  replace with date8(colname)
    CASE $DATE10:REPLACE sFunc WITH DATE10(sCol) IN sql '  replace with date10(colname)
   END SELECT                                           
  Loop                                                  ' loop
 Next                                                   'next    
END SUB