`its` isn't core to RSpec.  One the of the focuses of RSpec is on the documentation aspects of tests.  Unfortunately, `its` often leads to documentation output that is essentially lies.  Consider this spec:

``` ruby
User = Struct.new(:name, :email)

describe User do
  subject { User.new("bob") }
  its(:name) { should == "bob" }
end
```

```
$ bin/rspec user_spec.rb --format doc

User
  name
    should == "bob"

Finished in 0.00085 seconds
1 example, 0 failures

Randomized with seed 25153
```

It's not a true behavior of `User#name` that it always equals "bob".  `its` generally leads to output that is true in a specific case, but false in the general case, and doesn't help understanding when reading the documentation output.

Those who like `its` tend to really like it and want to continue to evolve it to do more and more powerful and terse things, such as [having it support arguments](https://github.com/rspec/rspec-core/issues/553). We're uncomfortable with making `its` more and more meta (it's already meta enough!).  We were planning on moving `its` into an external gem when we removed it from rspec-core, and @dnagir has already done that:

https://github.com/dnagir/its

Recently, we've also found some cases where there was some surprising, non-intuitive behavior with example groups that use `subject` and `its`:

https://github.com/rspec/rspec-core/pull/768#issuecomment-11918027

I think `its` gains you terseness at the expense of clarity, and in my judgement, it's a poor tradeoff.

I also feel like [rspec-given](https://github.com/jimweirich/rspec-given) is a better direction to go with one-liners. If you like one-liners, rspec-given encourages Given/When/Then one-liners, with no example docstrings at all.  It's more of a unified vision for this kind of thing than the `its` method in rspec-core.

Finally, you can read [@dchelimsky's thoughts](https://github.com/rspec/rspec-core/pull/306#issuecomment-758989) on `its` from a while ago.