The commit log of kohana/kohana on GitHub. I opened it in the summer and counted: a few merges a month, then fewer, then nothing. This year the official development basically stopped. Our projects did not stop working on that day. But the question came to my inbox three times since, so here is the answer.
What to do with a working Kohana product depends on which of four situations you are in.
A small site in support mode. Nothing. It will run for years. Watch PHP compatibility, apply security fixes when the community makes them, that is all.
An active product. The hard case. A full rewrite is expensive and dangerous, and the business will not wait a year to get the same features back. The plan that looks sane to me: keep the framework, write all new domain code framework-agnostic. Plain PHP classes. No ORM::factory() inside business logic. Controllers stay thin adapters. Every month the framework is a smaller detail.
A big legacy. Same as above, plus a risk people forget: hiring. Nobody young learns Kohana in 2014. In three years this will hurt more than any missing feature.
A new project. No. Laravel or Symfony, and move on.
The real risks are boring. Security patches, which volunteers still make, for now. New PHP versions. And the ecosystem: every year more libraries assume Composer and PSR, and fewer people write Kohana modules.
I had the rewrite proposal half written in September. Then I looked at how much of our code actually touches the framework. Less than I expected. The rest is our own mess, and a new framework would carry it over untouched.
Rewriting from scratch because of one announcement is emotion, not engineering. Measure your dependency. Then reduce it step by step.