Yes. FBO, shader (changing the currently active program, not necessarily shader state itself) and texture state changes tend to be the most expensive. Conversely, vertex pointers and uniforms tend to be the cheapest states to change.
It is almost impossible to actually calculate the expense of any one state change in modern GL implementations; you might pay a small validation cost up-front while the driver defers the heavy lifting until your next draw call or does certain tasks (e.g. pixel transfer data conversion) in parallel when possible. Rather than trying to profile down to the state change level, have you considered using OpenGL timer queries and partitioning your frame draw into a series of timed tasks?
Timer queries will give you a much better picture of how much time is spent actually doing work in the render pipeline. If you compare the time taken to finish a frame using CPU timers versus the sum of times taken for all pipeline tasks, that will give you some information about non-GPU related overhead. For example, if your entire frame finishes in 5 ms but the CPU blocks for VSYNC (let us assume 60 Hz), you will have a difference of 11 ms between the two numbers. That means there is 11 ms worth of idle GPU time per-frame (in this case because VSYNC is blocking). If you did not know how VSYNC works, that number would be very troubling ;)
In my own work, I calculate the time taken to build shadow maps, fill G-Buffers, composite lights, stream texture/mesh data, HDR post-process, apply anti-aliasing, etc. I can honestly say that knowing which state is the most expensive never delivers worthwhile optimization results but knowing which render task is bottlenecking, on the other hand, is an effective use of your time. You will probably figure out the former by solving the latter.