My English may have some mistakes so I write same sentences in Japanese later.

======================================================

My experimental environment:
・forge 14.23.5.2855
・jei_1.12.2-4.16.1.301
・HeatAndClimateLib_1.12.2-3.6.5
・HeatAndClimateMod_1.12.2-3.6.6

I tried to craft fuel coke container and dried dirt, and wait about 30min near this block but these recipes didn't worked.
of cource, I checked climate by checker and if other recipes work(ex. bronze dust block) and stopped weather and time change.
also, I added a custom recipe that it should work anywhere(all temp, all hum, all air) but less frequency recipe didn't worked.

======================================================

発生環境
・forge 14.23.5.2855
・jei_1.12.2-4.16.1.301
・HeatAndClimateLib_1.12.2-3.6.5
・HeatAndClimateMod_1.12.2-3.6.6

コークスコンテナと乾いた土の気候レシピを試し、 wikiにはプレイヤーの近くのチャンクでのみ動作するとあったので置いたブロックの近くで30分ほど放置しましたが、変化しませんでした。
気候チェッカーで気候が合っていること、青銅ブロックのような他のレシピは変化すること、放置で気候が変わらないよう天気と時間はコマンドで変化しないようにしておいたことは確認済みです。
また、apiから温度・湿度・通気に関わらず動作するレシピを追加してみましたが、そちらも低頻度のレシピは変化しませんでした。

======================================================

追記 / Edit (I'll translate later)
RandomTickの実装されていないブロックをRecipe inputに設定した場合低頻度レシピになり、Mod側から静的ブロックを更新する機能は実装されていない、とのことですが、本MODで実装されているレシピ(乾いた土等)もコンベアを使う必要があるのでしょうか？
また、RandomTickを持つブロックを材料とした場合、一律中頻度レシピとなる、という認識で宜しいでしょうか。

(序長な文を削除しました / I deleted unnecessary sentences)

Enable Vanilla Block Recipe = true にて、
以下の一枚目画像のような土→砂のレシピを追加、二枚目のように敷き詰めて放置しました。

Set Update Frequencyの値を1, 5, 100, 1000, 10000000に設定してそれぞれ試してみたところ、5の時に変化したのみで、それ以外のFrequencyでの変化は確認できませんでした。中頻度以上のレシピと比較して極端に変化が遅いという事でしょうか。

======================================================

ちなみに、ソースコードも参照させて頂きましたが、気候レシピに対応したブロックを自作Modで追加する場合、そのブロックはsetTickRandomly(true)のみで大丈夫でしょうか。あるいは、onClimateChange()等のHaC独自メソッドも追加する必要があるのでしょうか。

低頻度レシピはデフォルトで自然変化しません。コンフィグでONにすると機能します。
・Enable DropItem Recipe（ドロップアイテム状態のItemが機構レシピに従って変化）
・Enable Vanilla Block Recipe（プレイヤー周囲のブロックにTickUpdateを強制・一部バニラブロックへの気候精錬レシピ追加）
このあたりはPC負荷をもっと軽減しろという（主に海外ModPack作者方面からの）要求が非常に大きいのでデフォルトオフになっています。

また、ONにしても時間経過によって確実に変化する保証はないので、確実に使いたいのであればコンベアの利用を推奨します。
（このあたりはマイクラ自体がTickUpdateを極力抑えることで負荷対策をしているシステムなので、ONにすることでミリ秒単位でのTickスキップが増加するなど、PC負荷は大きくなります。逆に、流水が当たるなどバニラの仕様でTick更新が強制される場面では、不自然に早く進行してしまう場合もあります。）
ONにする場合、コンフィグのSet Update Frequencyの項目を小さくするとTick更新頻度が小さくなるので、ご自身の環境に合わせて調整してください。

また、wikiを参照していただいたようですが、私のwikiの表記の通り、仕様については2.X.Xまでの内容であり3.X.Xの内容には準拠していません。wikiの記述内容については保証しません。
3.X.X以降は公式情報としては同梱のReadMeのみに絞っています。（そのかわり、ReadMeはgithub上に公開してパッケージを開けなくても見えるようにしています。）
https://github.com/defeatedcrow/HeatAndClimateLib/blob/1.12.2_v3/main/resources/ReadMe.txt
https://github.com/defeatedcrow/HeatAndClimateMod/blob/1.12.2_v3/main/resources/ReadMe.txt
個別の仕様の疑問はここで問い合わせて頂くのも問題ないです。

変化頻度について

変化頻度は極端に遅いです。
具体的なTickUpdate発生イベントは『1200 / コンフィグ設定値』Tick経過毎に起こり、プレイヤーの周囲の9x9チャンクから3チャンクを選出、さらに選出チャンクから3ブロックを選出して、
world.scheduleUpdate(pos, block, 200);
で200Tick後のWorldUpdateを予約します。

丸石が苔になるレシピを入れていますが、『固定拠点にしている場所の周囲でたまに雨天時に苔が生えている』…というような、非常にゆっくりした自然変化を想定しているので、想定しているスピードはそのくらいです。

<追記>
もうひとつ注意点があり、PCの負荷が高くなってしまっていると、サーバーサイドでのプチフリーズが頻発し、Forgeの仕様でTickUpdateが数千Tick分くらい破棄されます。
Can't keep up! Did the system time change, or is the server overloaded? Running XXXXms behind, skipping XXXX tick(s)
こんな表示が頻繁にログに出ている場合は、スキップされたTickのBlock更新は無くなってしまいます。
このEventでの更新頻度を抑えめにしている理由の一つでもあります。

実装について

既存ブロックではなく自作であれば、方法が二通りあります。
あなたがどのようなブロックを作りたいかによります。

1. 作物のようにランダム成長させたい場合
   コンストラクタでsetTickRandomly(true)を設定しておけば問題ないです。

2. 条件を満たした後、確実に決まった経過時間で変化してほしい場合
   条件を満たしている間（HaCの鉱石粉ブロックのように）一定周期でレシピ判定を繰り返す必要があるので、setTickRandomly(true)だけでは不足です。
   バニラの仕様で、world.scheduleUpdateメソッドでTick更新を予約しない限りTick更新のタイミングを確定できませんので、独自ブロッククラスでは、onBlockPlacedByメソッド辺りの設置時に呼ばれるメソッドおよびupdateTickメソッドをOverrideしてworld.scheduleUpdateによる更新予約を行う必要があります。
   （そのあたりの、バニラ内部仕様に関する知見があれば問題ないと思います。）

HaCの内部処理では例えばこんな感じで実装しています
https://github.com/defeatedcrow/HeatAndClimateLib/blob/1.12.2_v3/main/java/defeatedcrow/hac/core/base/ClimateBlock.java#L50

下記の例ではforceUpdateフラグをtrueにしておいたブロックの場合のみworld.scheduleUpdateメソッドを呼んでいます。

	@Override
	public void onBlockPlacedBy(World world, BlockPos pos, IBlockState state, EntityLivingBase placer,
			ItemStack stack) {
		if (this.isForcedTickUpdate()) {
			world.scheduleUpdate(pos, this, this.tickRate(world) + world.rand.nextInt(21));
		}
	}

	@Override
	public void updateTick(World worldIn, BlockPos pos, IBlockState state, Random rand) {
		super.updateTick(worldIn, pos, state, rand);
		if (!worldIn.isRemote && state != null && state.getBlock() != null && canClimateUpdate(state)) {
			IClimate clm = this.onUpdateClimate(worldIn, pos, state);
			if (!this.onClimateChange(worldIn, pos, state, clm) && this.isForcedTickUpdate()) {
				worldIn.scheduleUpdate(pos, this, this.tickRate(worldIn) + rand.nextInt(21));
			}
		}
	}

HaCの独自ブロックが持っているIClimateObjectインターフェイス等のAPIは、気候変化するブロックの情報を外部から取りやすくする目的のインターフェイス（&HaCのブロックであるという識別用）なので、気候精錬のために実装する必要はありません。このインターフェイス（IClimateObjec）を実装しても、Block更新の部分は自作する必要があります。

ですのでHaCのBlockの内容に合わせる必要はなく、気候レシピへの登録と、バニラのBlock.updateTickメソッドが呼ばれる状況があれば問題ないです。

上記のClimateBlock.classを継承利用したり、参考にして頂くのも（ライセンスの範囲内の利用であれば）構わないです。
ただし、HaCの内部処理用の都合で入れてあるメソッドも含まれるので、他のmodに流用するのは少し使いづらい部分があると思います。