Honestly most all of your examples reek of everything wrong with people half-understanding functional programming and turning it into a hot WET mess.

Much less not knowing how to polyfill properly. Take your AJAX example with the functions for nothing, variables for nothing, IIFE/SIF for nothing, etc, etc. All to do what more properly should likely be more like this:

if (!window.XMLHttpRequest) Object.defineProperty(
  window,
  "XMLHttpRequest",
  { value : (
    Window.ActiveXObject ?
    function() { return new ActiveXObject("Microsoft.XMLHTTP") } :
    function() { throw new Error("No Ajax Support") }
  ) }
);

THAT is a polyfill. Because you can write your code normally/properly with XMLHttpRequest even in browsers that don't support it. And by using defineProperty the added method is non-enumerable and immutable.

Same for your includes polyfill with the broken numeric check (a painfully common problem), pointless length check that indexOf already does internally, and method of assignment. Seriously, defineProperty / defineProperties? Use it. A LOT.

if (!String.prototype.includes) Object.defineProperty(
  String.prototype,
  "includes",
  { value : function(search, start) {
    if (
      ("boolean" === typeof start) ||
      (parseFloat(start) != value)
    ) start = 0;
    return this.indexOf(search, start) !== -1;
  } }
);

Honestly a lot of what you're advocating are outdated and outmoded practices too if one can -- and probably sHOULD -- tell IE to sod off. That's my entire philosophy moving forwards is in deployment I use IE CC's to not send ANY scripting to IE, or I use an arrow function since that stops pre ECMAScript IE dead in its tracks.

As much as I dislike let/const, I will admit that in a LOT of cases used properly, they make the need for IIFE a thing of the past!

I mean if one can use ECMAScript, this is functionally identical to your IIFE without getting any excess call overhead involved.

{
  const
  
    castSpell = () => {
      console.log("Casting Fireball.");
    },
    
    shootSpell = () => {
      console.log("Shooting Fireball.");
    },
    
    doSpellDamage = () => {
      console.log("Do 111 Fire Damage.");
    };
    
  castSpell();
  shootSpell();
  doSpellDamage();
  
}

I was slow to come around to using these newer constructs, but I'm starting to see their superiority in practice. Most of the problem I was having with them was everyone else just throwing them willy-nilly at everything, hiding when/where they provide actual benefit.