When project grows up, the number of migrations starts to be pretty high, and as I look back, I see many migrations that could be refactored. Like merging create_posts and rename_posts_to_responses into create_responses.
Is this a bad habbit or should I encourage refactoring migrations?
You could but, later on in the project, you shouldn't really be running the migrations all the way up, you should be schema:load'ing, that is, if you need to start a completely new instance of the project. In my experience, you are going to be causing yourself more headache than anything else.
Doing a schema:load is a little difficult, though, if you've included data in your migrations (which happens to the best of us).
I've seen big projects where all migrations get substituted by one migration, taken from schema.rb. That's another reason not to use data migrations, and instead maintain a set of seed data.
in my opinion it is okay to refactor during development [though i would discourage it especially when working as part of a team], but it is too easy to mess up apps in production by refactoring migrations
Once you check in a migration to source control, I would recommend not altering them. I make a rare exception if there is a bug in one, but this is quite rare (1 in 100 maybe).
The reason is that once they are out in the wild, some people may have run them. They are recorded as being completed in the db. If you change them and check in a new version, other people will not get the benefit of the change. You can ask people to roll back certain changes, and re-run them, but that defeats the purpose of the automation. Done often, it becomes a mess. It's better left alone.
When you do get a large number of migrations, it can start to feel awkward. In general, though, you won't be running those that much. The only place we do this is on our integration server, which drops and recreates the database each run. So you can just not open that directory and pretend they are not there.
There is a practice of consolidating migrations. To do this, simply copy the current schema into a migration, and delete all the earlier migrations. Then you have fewer files to manage, and the tests can run faster. You need to be careful doing this, especially if you have migrations running automatically on production. I generally replace a migration that I know everyone has run with the new schema one. Other people have slightly different ways to do this.