TLDR: Probably about 0.05 blocks/tick² at the beginning and then 0.003 blocks/tick³ less acceleration every tick, double both for sprint flying. But it's not very clear.
I'll track my progress towards figuring out this value in this post.
First I used /data get entity @s to get my NBT data. That contains a bunch of recipe stuff and some other values that I don't need, but also the double list tags "Motion" and "Pos".
It seems like Motion is closer to what we want, so I made a display of it for the sidebar:
/scoreboard objectives add motion dummy
/scoreboard objectives setdisplay sidebar motion
/setblock ~ ~ ~ repeating_command_block{auto:1,Command:"execute store result score @p motion run data get entity @p Motion[0] 1000"}
The problem with that: The motion is something that both the server and the client can modify, there is anti-cheat, there are different types of movement, there are performance optimisations, etc., it's all very complicated and leads to Motion being unreliable to query with commands. It seems to only ever contain something different from 0 if you are in the air after a regular jump.
So on to the other tag: Pos. It also contains three double values and those are actually much more reliable, since client and server usually agree on it (except for lag and the 60fps/20tps difference). It also works while flying, gliding, etc.
The command is the same, just with Pos:
/execute store result score @p pos run data get entity @p Pos[0] 1000
You can get the current server-side motion of a player by subtracting his current position from the one in the last tick:
/scoreboard players operation motion pos = @p pos
<wait one tick>
/scoreboard players operation motion pos -= @p pos
This results in the fake player "old" containing the motion of the player, except negative. Since we don't care about direction, that doesn't matter.
This can be repeated to get the acceleration:
/scoreboard players operation acceleration pos = motion pos
<wait one tick>
/scoreboard players operation acceleration pos -= motion pos
The order of commands also matters. The repeating chain goes like this:
execute store result score @p pos run data get entity @p Pos[0] 1000
scoreboard players operation motion pos -= @p pos
scoreboard players operation acceleration pos -= motion pos
<any commands using that value>
scoreboard players operation acceleration pos = motion pos
scoreboard players operation motion pos = @p pos
Just from a quick look I can already see that this is not too reliable. Much better than Motion, but still not good. There are sometimes spikes on the order of tens of times as much as the usual values, sometimes there are values different from 0 while I'm standing completely still, etc. This is probably due to the mentioned reasons: Lag (even in Singleplayer there is a little bit, especially in 1.13+) and client/server disagreements.
I'll still present my results, maybe they have some value to you:
Regular flying: 49, 44, 41, 37, 34, 30, 28, 26, 22, 22, 18, 18, 16, 14, 13, 12, 11, 10, 8, 9, 8, 6, 494, -477, -493, 497, 5, 4, 3, 3, 3, 3, 2, 3, 1, 2, 531, -1057, 531, 1, 1, 1, 1, 1, 1, …
As you can see, there are quite some spikes, but in general, the acceleration seems to slow down the faster you are. So your speed doesn't grow linearly, but more similar to a square root function of the time. You start with an acceleration of ~0.05 blocks/tick² (since this display is 1000x the position/motion/acceleration), then it goes down by 5, 3, 4, 3, 4, 2, 2, 4, 0, 4, 0, 2, 2, 1, 1, 1, 1, 2, …, so on average 0.001 to 0.003 blocks/tick³, depending on where you cut it off.
Now the same for sprint flying: 78, 378, -114, 67, 62, -471, 526, 51, 46, 41, 777, -671, 28, -798, 824, 24, 911, -1759, 908, 15, 16, 978, -942, 11, -986, 995, 9, 7, 1032, -1013, -1030, 1036, 4, 5, 4, -1049, 2108, -1049, 2, 1069, -1062, 2, -1070, 1072, 1, 2, 1, 1079, -1076, -1079, 1080, 1083, -1081, 1, 0, …
This was a much more erratic test, so I'll filter out all the spikes: 78, 67, 62, 51, 46, 41, 28, 24, 15, 16, 11, 9, 7, 4, 5, 4, 2, 2, 1, 2, 1, 1, 0, …
Here the slowdown seems to be more on the order of 0.005 to 0.01 blocks/tick³ and the starting acceleration more like 0.1 blocks/tick², but it's really hard to say due to the spiking values.
I repeated both tests a few times, but it didn't get much clearer. I corrected the upper bound from ~0.08 blocks/tick² to ~0.1 blocks/tick³, but that's it.
More can probably only be said by looking at the code.
