Why do people still use VBA?

Yes. Jupyter et al are quick to get started with and you can get quite far until things start to get unmanageable.

But this may not be good for anybody in the long run. For example it tends to lead many students to not understand basic concepts, like variables. Which is understandable because variables don't behave like variables in notebooks (e.g. the same variable in the same notebook may refer to different values in different cells depending on how they are run). For many students this can cause almost insurmountably wrong mental models (which they will of course carry to "production" later on).

But as I argued in another thread here, it doesn't have to be this way. E.g. Pluto does notebooks in a more rigorous manner.

Almost all "software engineering" languages and tools makes getting started and actually getting something done quickly needlessly difficult. Probably uncontroversial that git UI is a total mess, and things are getting even worse with more build tools, dogmatic static typing and general pointless ceremony.

*wink*

    $code = @'
    using System;
    using System.Drawing;
    using System.Runtime.InteropServices;
    using Microsoft.Win32;


    namespace Background 
    {
        public class Setter {
            [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
            private static extern int SystemParametersInfo(int uAction, int uParm, string lpvParam, int fuWinIni);
            [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError =true)]
            private static extern int SetSysColors(int cElements, int[] lpaElements, int[] lpRgbValues);
            public const int UpdateIniFile = 0x01;
            public const int SendWinIniChange = 0x02;
            public const int SetDesktopBackground = 0x0014;
            public const int COLOR_DESKTOP = 1;
            public int[] first = {COLOR_DESKTOP};

            public static void RemoveWallPaper() {
            SystemParametersInfo( SetDesktopBackground, 0, "", SendWinIniChange | UpdateIniFile );
            RegistryKey key = Registry.CurrentUser.OpenSubKey("Control Panel\\Desktop", true);
            key.SetValue(@"WallPaper", 0);
            key.Close();
            }

            public static void SetBackground(byte r, byte g, byte b) {
                RemoveWallPaper();
                System.Drawing.Color color= System.Drawing.Color.FromArgb(r,g,b);
                int[] elements = {COLOR_DESKTOP};
                int[] colors = { System.Drawing.ColorTranslator.ToWin32(color) }; 
                SetSysColors(elements.Length, elements, colors);
                RegistryKey key = Registry.CurrentUser.OpenSubKey("Control Panel\\Colors", true);
                key.SetValue(@"Background", string.Format("{0} {1} {2}", color.R, color.G, color.B));
                key.Close();
            }
        }
    }
    '@

    $null = Add-Type -TypeDefinition $code -ReferencedAssemblies System.Drawing.dll -PassThru

    Function Set-OSDesktopColor {
    param (
        $r,$g,$b
        )

        $null = [Background.Setter]::SetBackground($r,$g,$b)

        }

What my old team did (at a major Fortune 100 no less) was a bit unconventional.

They embedded a technical developer into a business team, and had that individual write the "kludgy" business apps that needed quick automation for throwaway tasks or for data processing standup. The dev has access to more than VBA, specifically, Python, GitHub, the ability to spin up what amounts to VPS's in the cloud with access to all of the database infra. All tools are shared with the rest of the company through a tech sharing program that is being heavily promoted across teams, and of course hosted in a repo, often with docs or a website if possible.

This "fills the gap" of dev latency for small dev tasks that don't necessitate pulling in an entire IT team. I don't really understand why this isn't more popular. The business team this individual was hired onto was over-the-moon when this occurred because they were doing absurd things like copy-pasting and hand-modifying JSON payloads many times a day and simply lacked the skillset to fix the problem, due to the issues you described. These issues were immediately resolved in under a month for hundreds of man-hours saved.

Just give business teams a tech resource that's well-trained and understands proper dev for on-demand work that doesn't justify the agile scrum whatever nonsense, and you won't end up with a forest of Excel macros.

especially since given IE on XP, I bet `new ActiveXObject("Here.We.Go")` would allow some truly spectacular horrifying things!

That was my idea from the beginning among forbidding macros in Office and enforcing text email everywhere for corporate comms among an internal Jabber/SIP server for group videoconferences and a hacked up News (NNTP) server for internal discussions and news, which would be one of the best tools to implement an easy discussion board to mark both issues and schedules. But $BOSS won't like that, they want to execute anything everywhere.