Most transformations don't change the code that's executed.
const float x = sin(2);
const float y = 2;
If you define these two consts, we can inline y everywhere it's used. But by default, we don't inline x as it would lead to more work at runtime (maybe it doesn't matter for sin, but other function calls can be expensive). If you notice performance issues, please file a bug.
Renaming uniforms is optional (there's a flag). If you use C++, you can generate a .h header file that contains both the minified shader and macros that tell you how they've been renamed.
So Shader Minifier will generate macros like:
# define VAR_time "f"
to tell you that "time" is now called "f" and you can use VAR_time in your C++ code.
I cannot answer this for him, but I can speculate on the answer to your first question. The transformations he described his minifier applying do not change the code from the perspective of the compiler in any meaningful way, so the end result should have no performance difference. The only possible exception is the inlining, but the compiler likely would have done that anyway, so the end result should still have no difference.
To state that more precisely, everything is going to be translated into a SSA syntax in a compiler pass at some point. At that point, much of what he described should be either something the toolchain would have done (such as comment removal by the preprocessor) or effectively undone (such as the variable name reuse since by definition SSA makes each variable name be used exactly once). The rest should converge to the same result after subsequent optimization passes (such as an inlining pass). If you find a performance difference from using his tool, file a bug report with your compiler’s authors.
Dreams doesn't use gaussian splats as such, but we still learn a lot about how to compress and render a huge number of particles efficiently. (We're not doing half of this on PlayCanvas... yet).
