Yep, that worked, and it works well.
In fact, XEP-0301 mentions that an alternate smoothing method can be used as an alternative in the last bullet of Section 6.2.3.

However, because this standard is designed to benefit deaf people like me:
Some of us deafies are sensitive to 'emotion' in typing. People type differently when calm (smooth, typo free) or panicked (fast, lots of typos), or tired (slow, more typos). When we talk to the same person frequently, we can pick up the emotion partially from the typing, especially when supplemented with additional context (typed words, emoticons, etc). The spec encourages the use of high-precision transmission of delays in typing (Section 6.1.2), because that is more interesting than packet bursting (Section 6.1.1).

Time-based smoothing has the advantage of masking out typos especially if I do word transmission (giving the sender the opportunity to fix typos first). However, many deafies prefer seeing the original typing at high precision, for "maximum fidelity" of text-based communications.

The spec is being continually updated, to cover additional use cases, and this may be covered/clarified in a future update (since the spec is still in its Experimental stage, there is plenty of time to improve the spec; as XMPP.org gives every specification a mandatory minimum 12-month experimential period, before being upgraded to Draft status.)

I do need to correct that last sentence.
As shown in the animation, "you can transmit a multiple keypresses in only one packet per second. And yet keep the typing smooth."

There's an excellent reason for the XML (in)elegance.
- We first tried a compact binary protocol, base64 encodings, and other alternate encodings.
- But, XMPP prefers XML-based protocols.
- We wanted ease of software development, so ease outweighed a lot of factors.
- Deaf-friendly: Something that can be added to existing traditional chat interfaces in existing chat software (much like AOL's proprietary Real-Time IM, but as an open standard). It can be turned on/off
- We chose delibrately short XML tags to reduce bandwidth. Yes, that does not follow XML philosophy in naming, but it is a bandwidth compromise.
- We delibrately avoided using tag names of existing HTML tags, even though this is a different XML namespace. We avoided <b> and <i> anyway.

First, see the animated GIF of this real-time text protocol, to see some of the reasons why this XML was chosen:
http://www.marky.com/realjabber/real_time_text_demo.html

Now read section 7.1 through 7.9 of the XEP-0301 specification:
http://xmpp.org/extensions/xep-0301.html#action_elements

As you can watch in the animation,
<t> is insert text, to support transmission of key presses, text block inserts, and text being pasted.
<e> is backspace.
<d> is delete key (forward delete), or cutting / deleting blocks of text
<c> is cursor positioning (optional)
<w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth.
<g> is for backwards compatibility with similiar features like Yahoo Buzz, MSN Nudge, BlackBerry Ping, Jabber XEP-0224 Attention, etc. It is very deaf-friendly and this is optional and can be turned off, but some like this feature.

More info about these action elements:
http://xmpp.org/extensions/xep-0301.html#action_elements
Only the first 3 XML elements are required (insert, backspace, and delete)

So as you can observe, there is excellent rationale for the "turd" we had to use. It is for instant messaging conversations, not for things like Google Wave, and is rather instead an optional add-on to existing instant messaging that can be turned on/off.
http://www.marky.com/realjabber/real_time_text_demo.html

Darn near everybody else has it:

Yahoo Buzz
BlackBerry Ping
Windows Live Nudge
XMPP.org's XEP-0224 "Attention" (for Jabber / XMPP / Google Talk / etc)

This is a protocol optimized for assistive use for the deaf, too; and it can be turned on/off. (i.e. real time text is optional) This really, is an unobtrusive add-on that can be off by default (much like AIM's existing real time text feature is off by default)

Unfortunately, deafies are stuck with this:
http://en.wikipedia.org/wiki/TDD/TTY
That's 45 baud.

It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf, and is potentially a replacement for TDD/TTY over the long term.

Hello --

Some general comments that addresses common comments:

(1) This is an optional feature that can be turned on/off.
You only use it when you want it, so you don't have to show off your typos to everyone, if you don't want to.
Just like audio can be turned on/off and video can be turned on/off.

(2) It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

(3) It's not inefficient in message rate. It is only one packet per second, no matter how fast you type, even 30 keypresses per second (holding a key down). As far as I know, this is the world's first real-time text protocol that preserves key-press delays for chats. This means typing still looks smooth, even at low packet rates (1 packet per second), even if you are typing at 10 or 30 keypresses per second. Even over a satellite connection, or even over a dial-up connection (while an FTP is going on in the background), or over a mobile phone connection that has intermittent reception and variable ping latency.

(4) There is an animation of the key press intervals (delay coding) at:
http://www.marky.com/realjabber/real_time_text_demo.html

(5) Some existing software already have this feature, that you may not notice, because it's off by default. For example, AOL Instant Messenger's "Real-Time IM" feature is a proprietary version of real time text, while XEP-0301 is an open standard that anyone can use for Jabber-based networks.

I know. :-)
One thing though, that isn't HTML, it's XML over XMPP. We used a binary code at first for XEP-0301, until I realized XMPP encouraged XML. Our task group chose one-letter XML elements, to save some bandwidth. Key press interval elements ended up being the best way to transmit real-time text, at only 1 packet per second (protecting the network), while fully preserving key-press delays, so that typing comes out naturally, thanks to the delay elements:
http://xmpp.org/extensions/xep-0301.html#key_press_intervals

See examples 7.1 through 7.9:
http://www.xmpp.org/extensions/xep-0301.html

As well as the animation of smooth typing (non-bursting text) even at just 1 packet per second:
http://www.marky.com/realjabber/real_time_text_demo.html

This feature can be turned on/off.

It is a feature that is very friendly to the deaf, as the spec even mentions deaf people in the introduction of the specification document.
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

It's a good assistive technology feature for the deaf too. In fact, the Introduction also mentions its use by the deaf, too:
http://xmpp.org/extensions/xep-0301.html
"Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

- It's an optional feature, that can be turned on/off as usage warrants
- Just like audio can be turned on/off, and video can be turned on/off, real-time text can be turned on/off
- It utilizes traditional instant messaging UI, too.

It's also found in AOL Instant Messenger's Real-Time IM
http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568
However, we all wanted an open standard, that works on unmodified Jabber/XMPP, and that is how XEP-0301 got developed.

I actually thought of this.
XMPP real-time text is the world's first real time text protocol that encodes key press delays:
http://www.marky.com/realjabber/real_time_text_demo.html

So even at 10 keypresses per second, even over a satellite connection (or other high-latency bursty connection), it only needs to transmit 1 packet per second, and the typing comes out naturally.

XEP-0301 (the protocol) is a packetization of typing including typing delays, much like VoIP packetizes short snippets of audio.
Explained in first section in section 6:
http://xmpp.org/extensions/xep-0301.html#implementation_notes

Understandable, but real-time text can be turned on/off.
Some users like, it and some don't. AIM has an enable/disable feature for Real-Time IM.
It can be an optional feature, like optional audio or video in their IM chats.
I'm a deafie, and it's beneficial to use from time to time.