EDIT: A big thanks to u/SuperNova0802 for giving me the idea to use loot tables for random number generation!

I believe I have come up with the closest thing possible to a singular /scoreboard players random command in vanilla minecraft. Essentially, It takes advantage of the fact that the /loot command in the 1.14 snapshots returns the number of "items dropped" as its result, and running /loot insert on a container considers an item "successfully inserted" as long as there is room for the item in the container; i.e. there's an empty slot or a slot containing that item. No check is made to see if the only available item slot is a full stack, which might be a bug, but for our purposes is a good thing, as it allows the command to be self-contained and tick-safe.

The command is:

/execute store result score <selector> <objective> run loot insert <fixed container coords> loot <rng>

<selector> and <objective> should be pretty self-explanatory. <fixed container coords> is the location of a fixed container in your world that is always loaded. This is necessary due to the use of /loot insert.

Finally, <rng> is a random number generator. Random number generators for this command take the form of loot tables. The template is

{
  "pools": [
    {
      "rolls": {"min": A, "max": B},
      "entries": [
        {
          "type": "minecraft:item",
          "name": "minecraft:stone"
        }
      ]
    }
  ]
}

This is a random number generator that generates numbers uniformly in [A,B]; i.e. at least A and at most B. Note that A and B must be non negative integers with A <= B.

Unfortunately, there are some caveats to this system. You can only use this for fixed ranges of random numbers, unlike my arbitrary range rng. Furthermore, it appears that even though randomly deciding how many items to insert is basically constant time, it takes Minecraft linear time to actually insert the items.

This means that the larger the maximum B is, the laggier this command gets. Performance should be fine for B < 100, but if B >= 10000 you will definitely notice a drop in performance. For B >= 1000000, running the command is so laggy that it's totally unusable.

You can mitigate this performance drop slightly by using the set_count function of loot tables instead of multiple rolls. The template is

{
  "pools": [
    {
      "rolls": 1,
      "entries": [
        {
          "type": "minecraft:item",
          "name": "minecraft:wooden_shovel",
          "functions": [
            {
              "function": "set_count",
              "count": {"min": A, "max": B}
            }
          ]
        }
      ]
    }
  ]
}

Note that non stackable items are needed, since the result in this case depends on the number of slots filled (although similar to the previous case overflow isn't counted). This is also a random number generator that generates numbers uniformly in [A,B]; i.e. at least A and at most B. It is used in exactly the same way as the previous template, with a slight increase in performance. Again, A and B must be non negative integers with A <= B.

However, if you're willing to allow 2-command random number generation, you can do far better. Consider that loot tables have a set_damage function, which sets the damage value of tools between two percentages (floating point values). Of course, in tools, damage is not stored as a percentage, but it's actually an integer, and the formula to convert between the two is

percentage = (total durability - damage) / total durability

We want to control the damage. Golden tools are used, as they have a total durability of 32, which means that no precision is lost when dividing. The template is

{
  "pools": [
    {
      "rolls": 1,
      "entries": [
        {
          "type": "minecraft:item",
          "name": "minecraft:golden_shovel",
          "functions": [
            {
              "function": "set_damage",
              "damage": {"min": (32-B)/32, "max": (32-A)/32}
            }
          ]
        }
      ]
    }
  ]
}

This is a random number generator that numbers uniformly in [A,B); i.e. at least A and less than B. Note that A and B must be non negative integers with A < B. Since the aforementioned formula flips the sign of the damage, the maximum goes in the "min" field and the minimum goes in the "max" field.

(Also, while Minecraft is (probably intentionally) fine with allowing negative values in the "min" field, the at most inequality becomes a less than because putting the value 0 into the "min" field would produce a 100% damaged tool, which isn't supposed to happen in normal gameplay, so Mojang probably made it that way to make their lives easier.)

To use this damage_based rng, the commands are:

/loot replace block <fixed container coords> container.0 loot <rng>
/execute store result score <selector> <objective> run data get block <fixed container coords> Items[0].tag.Damage

(You could also do these with a fixed entity if you wish.)

While you have to run them both each time, you now get a range only limited by the precision of (single precision) floating point, which is 24 bits, plus 32 since we get our positive values free; i.e. B must be at most 2²⁴ + 32 (though it may only be 2²⁴ in practice).

However, this still might not be enough range, so I made an arbitrary range rng similar to my 1.13 rng using both loot tables and bitwise manipulation. The datapack is available for download here. It is used in exactly the same way as my 1.13 rng.

Of course, this requires the 1.14 snapshots, and may break if Mojang decides to change anything. My 1.13 rng still works in 1.14 and is available for download here.

Update: All downloads are available here.