-Actually makes the code cleaner.
-Above all, actually results in there being less code than there was before.
If you can achieve clean code + negative lines of code after a refactor, with identical functionality, they'd be fools to not merge it.
It's possible the refactors you submitted didn't meet these requirements. Or the project owners simply were too possessive of the code they wrote with their own fingers.
Isn't that sort of contrary to OSS?
No, OSS is a licensing model not a development model. With OSS, if the existing project has a dev model you don't like, you can always fork it and start a project with a dev model you do; with proprietary software (even if the source is available), if you don't like the development model (among other things you might not like) you're, well, forked.
Either that or the project owners/maintainers have a lot of pride.
Even if you overlook that getting code that matches a projects style guides might be rarer than it should be refactoring (at least in most cases that I need to deal with it) requires a good understanding of how everything fits together and a better idea of how it should work. There are some simple cases in which this might not be the case at all, such as grouping together a whole bunch of copypasta style code, but even under those circumstances any refactoring is likely to yield a fair bit of work for the maintainer to verify (regressions/style/changed organization) with fairly limited benefit.
As such it doesn't really seem that effective to try to impose something like this on a project without a good justification. If a good justification can be made, then sure refactor away, but otherwise the maintainer would logically think that the work was a waste of everyone's time.
I guess "small" is key. I agree a large refactoring would be troublesome to verify.
Answering questions on Stack Overflow / mailing lists / issue trackers can be a good way to build up trust in your abilities and a working relationship with other contributors.
Often projects label things that are "good for a first commit" and you should check out those.
All that said, most projects are eager to include new people, and personally I enjoy helping new contributors feel comfortable and get their commits accepted.
Tests are a way to delegate trust. Instead of trusting the developer, you trust the code. It's a huge huge relief. If you can remove that burden from the shoulders of the maintainers, I guarantee you will be welcomed with open arms.
The side-effect is that you don't need to _add_ content/functionality, so the maintainers don't have to think about your new shiny feature. And if you fix something that was supposed to work in their own view of the project, then you start being noticed.