While win32ole is not built on Linux and it used to not be installed. But the .gemspes is installed now. I believe that this is due to https://github.com/ruby/ruby/pull/5206.
Besides the win32ole.gemspec being installed now, I think that the PR should be completely reverted, because the gem extensions are not build probably due to https://bugs.ruby-lang.org/issues/18373 and not because of statical linking. The gems should have build extensions no matter if statical linking is enabled or not, so the analysis of the issue is wrong IMO.
#18373 is completely different from the issue that the pull request tried to fix. The pull request is about default gems, and #18373 is about bundled gems.
I wonder if you misunderstand --with-static-linked-ext. The configure option is completely different from gcc -static or something. It is to statically link the ruby interpreter with default gem extensions that are specified by --with-ext configure option. For example, when ./configure --with-static-linked-ext --with-ext=stringio is specified, ext/stringio/stringio.c is compiled, but no stringio.so is generated. Instead, it is statically linked with the interpreter itself. On the interpreter, require "stringio" does not search stringio.so, but just enables StringIO module. The pull request tried to make stringio.gemspec installed because rubygems requires the file even under this mode (i.e., no stringio.so is generated). But indeed, it looks good to avoid win32ole.gemspec to be installed under Linux. Maybe the pull request should be improved so that it install only gemspec files specified by --with-ext. (BTW, currently --with-static-linked-ext does not support bundled gems at all.)
That explanation makes sense and the "Ignoring debug-1.3.4 because its extensions are not built. Try: gem pristine debug --version 1.3.4" is just red herring there and therefore the PR is legit.
Nevertheless, the point that win32ole.gemspec should not be installed stays and #18373 would deserve some love (ideally prior 3.1 release).