Saving a list of Materials instead of per-Renderer fundamentally ignores MaterialPropertyBlocks
Since only the material is passed into the "ExportMaterial" method, and not the renderer, all MaterialPropertyBlocks on that Renderer are ignored. That means that scenes where MaterialPropertyBlocks are used (which are many, since this is the preferred way to re-use materials between objects with different cbuffers) export incorrectly.
Thanks for the suggestion @soraryu.
One challenge of supporting MaterialPropertyBlocks in the way you suggest is that they don't map well to any properties in gltf. See gltf 2.0 Materials spec. There is some discussion around adding support for asset variants, which might map reasonably well to Unity's concept of MaterialPropertyBlocks.
But unless and until asset variants are added to the gltf spec (or as an extension), then I think the best we could do would be to have ExportMaterial() take in an optional MaterialPropertyBlock. If one is present, then it would need to do some checking to determine if its properties match an existing material+materialpropertyblock entry in the Materials list.
@soraryu , if this is of interest to you, you can create a fork, implement the change, and submit a pull request. We would appreciate any contribution you could make in this area.