I don't know the tick rate of AC. But yesterday i was trying this X2010 red bull car mod on nordschleife in AC. Its like going over a dirt road, so i think the tick rate is quite high as well.
That's now how tick rate can be perceived

It's not only physics tick rate, but the game input rate and wheel FFB update rate also factors in how much detail one received. So, we have physics tick rate - input rate - wheel FFB update rate = what driver feels.
Most steering wheels like DFGT, G27, Fanated GT3, T500RS are at most 500Hz with 2ms delay and 9-20+ms latency ( with latency, the game frame rate also related in how the driver can respond, but most games are in 60fps anyway ) So, no matter how high the game physics tick rate and input rate, the wheel FFB rate ultimately decide how much details the driver received. Expensive wheels said can have up to 1000Hz FFB rate

which is higher than most if not any sims out there, AMS runs at "upscaled" 720Hz physics rate and 500Hz input rate.
I have read before that AC is about 300-400Hz in physics tick rate and the highest the traction control system used in AC has 400Hz tick rate, but anyone with info from Kunos, feel free to correct me
There's a way to test how high physics tick rate ( roughly ), but it's not accurate measure. Physics tick rate influence the stability of the physics when dealing high/large force on a small mass, when tick rate is not high enough, strange things happen that often seen as glitch like jumping cars. When a game limits the damper highest value or spring value on cars in lighter mass range, then this is usually caused by the limitation in physics tick rate.
This is what LFS dev, Schawen said on the matter and why he set LFS to run at 2000Hz :
"One example in LFS is the spring above the wheel which is supported by a tyre below. The wheel is light compared with those two large spring effects and can easily cause instability. That is the reason for LFS's high update rate of 2000 Hz in the sub-updates, which avoids the cars jumping up and down all on their own due to jumping wheels! You saw in the google video, at one point, in a crash when some vertices went a bit wrong.
What happens is you have some very stiff springs for the chassis members, supporting a node which let's say is 10 kg. The physics engine finds out in one update that the springs are stretched by 5 cm. Now the super string spring applies a force of [A LOT] to that 10 kg mass. So in the next update you find that 10 kg mass has gone maybe 10 metres away or whatever, when really it should only have moved a mm or so.
The update time steps must be small enough so that large force acting on the small mass at the node, doesn't push the node too far away."
So, simple test, crank up the damper and spring rate on lightweight race cars in AC, and see if strange thing happen when driving on the track ( if Kunos didn't limit these yet )
This is a list of some games physics tick rate that I gathered from LFS forum :
'98 Sports Car GT - 50 Hz [from Blackhole Motorsports article]
'98 Viper Racing - 60 Hz (general) / 300 Hz (some aspects) [email with Dave Broske]
'98 Grand Prix Legends - 144 Hz
'00 F1 2000 - 50 Hz [from Blackhole Motorsports article]
'00-'08 Racer - 300 Hz (general) / 3000-30,000 Hz (tyre rotation) [posted by Ruud in a thread archive on racer.nl, dated '01]
'01 F1 2001 - 200 Hz [from Blackhole Motorsports article]
'02 Total Immersion Racing - 100 Hz (uses RK4) [from press release]
'02-'08 Live For Speed - 100 Hz (collision detection) / 2000 Hz (vehicle dynamics) [posted by Scawen on lfsforum]
'03 NASCAR Racing 2003 Season - 288 Hz (possibly)
'04 VirtualRC Racing v1.0 - 300 Hz (general) / 600 Hz (tyre model) [posted by Todd on lfsforum]
'05 VirtualRC Racing v3.0 - 250 Hz (general) / 500 or 1000 Hz (tyre model) [posted by Todd on lfsforum]
'05 rFactor - 400 Hz
'05 Forza Motorsport - 180 Hz
'06 Test Drive Unlimited - 100 Hz (collision detection) / 1000 Hz (vehicle dynamics)
'06 netKar Pro - 333 Hz [posted by Kunos on RSC]
'07 Forza Motorsport 2 - 360 Hz [from wikipedia article]
'07 Rigs Of Rods - 2000 Hz [from ROR forums]
'08 Ferrari Challenge: Trofeo Pirelli - 60 Hz
'08 rFactor Pro - 800 Hz [from official website]
'08 iRacing - 360 Hz [from AutoSimSport]
'09 Supercar Challenge - 60 Hz
'09 Need For Speed: Shift - 180 Hz / might be 360 Hz (effective due to 2 physics passes per timestep?)
'09 Forza Motorsport 3 - 360 Hz [from gamespot article]
Motorsport - 333 Hz (but still being tuned) [posted by Stenyak on RSC]
UPDATE : ASSETTO CORSA - 250Hz - from Kunos presentation on console port/dev.
AC didn't go much higher than Kunos previous release Netkar Pro if 400Hz is true.
The Automobilista runs upscaled 720 Hz physics and 500 Hz input rates (vs 360 Hz &100 Hz respectively in SCE) ( Reiza own statement )
So, when playing with wheel, make sure it's setup at highest update rate to fully utilized the wheel ability.
In relation to laser scanned track details like bumps to physics tick rate, Iracing has 360Hz, and most drivers average speed on the track would be higher than 100kmh, rarely do driver go below 50kmh when racing or time trialing. Say a driver goes to 100kmh, or 27.77m per second, with physics at 360Hz ( 360 refresh per second ), 27.77x1000/360 = 77.138mm, that's the most detail a driver can feel from the road when driving at that speed, not considering the wheel FFB rate. If wheel FFB is capable of more than 360Hz update rate, than driver can enjoy what the physics provide. What if the driver goes slower at 50kmh ? 13.888x1000/360 = 38.58mm, at slower speed, the driver can hypothetically sense more of the road surface details within 38.58mm distance accuracy ( 4cm ) going at 13.88m/s. The faster the driver goes, the longer the distance for details, 200kmh = 154.27mm. Iracing input rate is 120Hz ( from what I read on other forum ), that means what the wheel FFB can receive is limited to the 120Hz rate, and at 50kmh, that would be 115.73mm ( can a driver accurately sensed 11.5cm FFB detail like little bumps going at 13.88m/s ) , 100kmh = 213.41mm and at 200kmh = 462.95mm ( 46+cm )
I think this is one of the reason why Iracing said to have spaced the physical mesh/vertices to 0.3m / 30cm to balance between physics rate/input rate/system load ( the lower the spacing in physical mesh/vertices, the heavier the calculation ), which should be clear by now, that laser scan mm accuracy is often just marketing/selling point. All of this is based on what I understand from LFS forum discussion and other forum on physics/laser scan and FFB rate, so I may make a mistake, please correct me if I'm wrong
A list of wheel update rates ( old source )
http://www.insidesimracing.tv/forums/viewtopic.php?f=159&t=4327
Code:
Logitec G25 (900 deg)
500 hz update rate (2ms delay)
9-10 ms latency (first move)
Logitec G27 (900 deg)
500 hz update rate (2ms delay)
9-10 ms latency (first move)
Fanatec GT3 (900 deg)
500 hz update rate (2ms delay)
14 ms latency (first move)
Thrustmaster T500RS (tested at 900 deg, 1080 deg total)
120 hz update rate (8ms delay)
- Have been updated to 500Hz in 2012, FW V40 and on
20-23 ms latency (first move)
Logitec DFP (Driving Force Pro) (900 deg)
120 hz update rate (8ms delay)
28 ms latency (first move)
Red Momo (240 deg)
120 hz update rate (8ms delay)
44 ms latency (first move)
Black Momo (240 deg)
120 hz update rate (8ms delay)
35 ms latency (first move)
Saitek R660 GT (180 deg)
120 hz update rate (8ms delay)
44 ms latency (first move)
Sidewinder 2 joystick
34-37 ms latency
8 ms update rate
Logitec Force 3D joystick
34 ms latency (67 & 74 with wind up at end of travel)
8 ms update rate
Thrustmaster F430 (270 deg)
60 hz update rate (16 ms delay)
38 ms latency (first move)
ECCI 7000 (900 deg ?)
60 hz update rate (16 ms delay)
43 ms latency (first move)
Microsoft Sidewinder Wheel USB (red) (240 deg)
60 hz update rate (14-16ms delay)
44 ms latency (first move)
***Driver takes 8-16ms just to return from a call to getPosition and
setForce
Logitech Driving Force GT (DFGT) (900 deg)
500 hz update rate (2ms delay)
17 ms latency (first move)
VPP
56 ms latency
8ms update rate (driver takes 24 ms after update!)
calls to getPosition take 8-16 ms to return and up to 56 ms when applying a
force!
Frex
44 ms latency
16 ms update rate