Yes and no. If you are using it correctly, I think it's fine. If what you really need to store is an array, it would be silly to try and break it up. You have a chunk of data that needs to be saved as a unit. That's fine. Who cares if it's an array? Strings are basically arrays of characters. Would it be more normalized to have a character table in the database, as well as a string table, and anytime we need to create use a string in some field on some user table (or whatever) point it to a string record which points to a bunch of character records? Clearly not.
Obviously there are situations where it is a bad idea to serialize. For example, when you are trying to store multiple foreign_keys in serialized arrays. There, you're starting to get into the realm of hackishness and are liable to break something. And you definitely wouldn't want to serialize an array of employee objects for storage in a company's employees array attribute. That is even more obviously a bad idea. But storing an array of integers? That is a fundamental enough chunk of data that I think it is fine to think of that as primitive. But as the case of foreign keys illustrates, it depends on what you need the integers for and what they represent.
I think that the bottom line is that it's important not to follow guidelines of normalization (and other design principals) to the point where it (they) become(s) a thorn in your side. If you find that you are having to jump through half a dozen hoops just to have what seems to be a more normalized database, you need to ask yourself whether it was worth it. Normalization is there so that we save ourselves time and have a cleaner way of thinking about that data that we are dealing with. If we end up making our application significantly more complicated and/or awkward just to normalize, it kind of defeats the purpose. Sort of a forest for the trees scenario.
Besides, rails does give us serialization support. If it was never an admissible thing to do, they probably wouldn't even give you the tools.